Did I write a good (efficient) program?
in [Cobol]
|
From: Rick Smith on 3 Apr 2008 20:31 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:65k1fkF2gdg4dU1(a)mid.individual.net... > > > "Rick Smith" <ricksmith(a)mfi.net> wrote in message > news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d(a)mid-floridainternet... > > > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > > news:65fmhdF2fbsenU1(a)mid.individual.net... > > [snip] > >> To modify existing functionality does NOT mean modifying a base class. It > >> means extending (through inheritance) or over-riding existing behaviours. > > > > The priniples of object-oriented design do not include > > the use of inheritance to overcome inadequate or faulty > > design. In such cases, modifying a base class may be > > unavoidable. > > I have never encountered such a situation and do not expect to. (Guess my > designs are not "inadequate" or "faulty"...:-)) > > I really don't care about academic "principles of OO design" unless they are > pertinent to the world in which I live and work; your statement above is > not. > > My own principles (derived from over a decade of real world use) tell me not > to modify a Base Class. > > So I don't. Therein lies the problem, Mr Dashwood! While you advocate the OO paradigm, you don't actually use it--preferring your own principles to those of the paradigm. <g>
From: Pete Dashwood on 4 Apr 2008 00:14 "Rick Smith" <ricksmith(a)mfi.net> wrote in message news:l6KdnaVTeOZ762janZ2dnUVZ_rSrnZ2d(a)mid-floridainternet... > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:65k1fkF2gdg4dU1(a)mid.individual.net... >> >> >> "Rick Smith" <ricksmith(a)mfi.net> wrote in message >> news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d(a)mid-floridainternet... >> > >> > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message >> > news:65fmhdF2fbsenU1(a)mid.individual.net... >> > [snip] >> >> To modify existing functionality does NOT mean modifying a base class. > It >> >> means extending (through inheritance) or over-riding existing > behaviours. >> > >> > The priniples of object-oriented design do not include >> > the use of inheritance to overcome inadequate or faulty >> > design. In such cases, modifying a base class may be >> > unavoidable. >> >> I have never encountered such a situation and do not expect to. (Guess my >> designs are not "inadequate" or "faulty"...:-)) >> >> I really don't care about academic "principles of OO design" unless they > are >> pertinent to the world in which I live and work; your statement above is >> not. >> >> My own principles (derived from over a decade of real world use) tell me > not >> to modify a Base Class. >> >> So I don't. > > Therein lies the problem, Mr Dashwood! While you advocate > the OO paradigm, you don't actually use it--preferring your own > principles to those of the paradigm. <g> And how is having things work properly, a "problem"? I use the OO paradigm, I may differ with you over interpretation of some aspects of it. Fortunately, I don't need your or your Professor's approval, nor anything written in a text book, in order to make money with it. No problem. Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 4 Apr 2008 01:38 On Thu, 3 Apr 2008 18:31:09 -0600, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote: >I'm not talking about how the Cobol standard has them specified. Just that, >as a feature, I would like some better way to work with variable length >strings. > >With regard to DIRECT... Without actually reading the standard, here is >what I would intuitively *expected* with regard to a direct "any length" >data item (fixed length font required for this to make any sense at all!): > >01 AN-01-DATA-AREA. > 05 FIXED-STR-10 PIC X(10). > 05 VARIABLE-STR-10 PIC X ANY LENGTH LIMIT IS 10 DELIMITED BY X'00'. > 05 A-CHAR PIC X. > > >MOVE 'XXXXXXXXXX' TO FIXED-STR-10 >MOVE 'TEST' TO VARIABLE-STR-10 >MOVE 'Z' TO A-CHAR >MOVE 'YYYYYYYYYY' TO VARIABLE-STR-10 > >Result in memory, before the final MOVE: >XXXXXXXXXXTEST_ Z >^^^^^^^^^^^^^^^^^^^^^^ >After the final MOVE: >XXXXXXXXXXYYYYYYYYYY_Z >^^^^^^^^^^^^^^^^^^^^^^ >The underscore represents the delimiter 'null' character. > >What you say says to me that before the final move we would instead see >XXXXXXXXXXTEST_Z That's what you'd get if you moved the group to a flat string. The standard doesn't say what memory would look like. It does say the address of a-char will not change if the any-length string is indirect (is represented by an inline pointer). I take that to mean the address of a-char MIGHT change if the any-length string is direct. The compiler author gets to decide whether to shift a-char when its neighbor changes length. >I would agree that this is rather crazy. > >I think how I am looking at it, which is apparently not how you would >support it, is that if DIRECT is specified *along with a limit*, then the >maximum storage required would be used. This is just like how in C you can >have, for instance: > >struct my_struct { > char[21] field1; > char[21] field2; > char x; >}; > >void cfunc(struct my_struct *s) { > strcpy(s->field1, "This is a test"); > strcpy(s->field2, "Another test"); > s->x = 'X'; >} > >Result in memory: >This is a test_ Another test_ X >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >If I wanted to call cfunc from Cobol I could do this: > >01 MY-STRUCT. > 05 field-1 PIC X ANY LENGTH LIMIT IS 20 DELIMITED BY X'00'. > 05 field-2 PIC X ANY LENGTH LIMIT IS 20 DELIMITED BY X'00'. > 05 X PIC X. > > >CALL 'cfunc' USING MY-STRUCT >DISPLAY field-1 '/' field-2 '/' x > >Result: >This is a test/Another test/X Compatibility with C is a non-issue because .. get this .. you are NOT ALLOWED to pass a variable length structure as a CALL parameter. I seriously doubt any compiler author would enforce that restriction. Then, to be compatible with C, he would NOT shift X around. >Now as for a DIRECT any-length data item without a limit specified, I don't >think that makes sense. Is it even allowed? My brain doesn't want to try >to interpret the standard right now. DIRECT items must have a LIMIT except at the 01 level. If you leave it off, they default to INDIRECT. >n 4/1/2008 at 8:54 PM, in message ><vzCIj.8760$fY6.7941(a)fe11.news.easynews.com>, William M. >Klein<wmklein(a)nospam.netcom.com> wrote: >> Frank, >> As currently included in WD 1.10, I am very much opposed to it. The >> problem >> is that the current definition allows the data to be stored within the >> structure >> ("DIRECT") and to have such items within ODO's and with data after this. >> What >> this means is that the "data" after the variable length field MUST be >> "moved" in >> storage each time the variable data size changes. >> >> If the proposed definition >> - only allowed for "direct" variable length fields at the 01-level, >> - allowed for "indirect" variable length items within structures >> - figured out how to handle such fields within FILES (or disallowed it >> there), >> - didn't allow the same variable length field to be BOTH prefixed and >> suffixed >> >> then I would be for it.
From: Rick Smith on 4 Apr 2008 06:05 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:65lo9dF2gqp30U1(a)mid.individual.net... > > > "Rick Smith" <ricksmith(a)mfi.net> wrote in message > news:l6KdnaVTeOZ762janZ2dnUVZ_rSrnZ2d(a)mid-floridainternet... > > > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > > news:65k1fkF2gdg4dU1(a)mid.individual.net... > >> > >> > >> "Rick Smith" <ricksmith(a)mfi.net> wrote in message > >> news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d(a)mid-floridainternet... > >> > > >> > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > >> > news:65fmhdF2fbsenU1(a)mid.individual.net... > >> > [snip] > >> >> To modify existing functionality does NOT mean modifying a base class. > > It > >> >> means extending (through inheritance) or over-riding existing > > behaviours. > >> > > >> > The priniples of object-oriented design do not include > >> > the use of inheritance to overcome inadequate or faulty > >> > design. In such cases, modifying a base class may be > >> > unavoidable. > >> > >> I have never encountered such a situation and do not expect to. (Guess my > >> designs are not "inadequate" or "faulty"...:-)) > >> > >> I really don't care about academic "principles of OO design" unless they > > are > >> pertinent to the world in which I live and work; your statement above is > >> not. > >> > >> My own principles (derived from over a decade of real world use) tell me > > not > >> to modify a Base Class. > >> > >> So I don't. > > > > Therein lies the problem, Mr Dashwood! While you advocate > > the OO paradigm, you don't actually use it--preferring your own > > principles to those of the paradigm. <g> > > And how is having things work properly, a "problem"? > > I use the OO paradigm, I may differ with you over interpretation of some > aspects of it. > > Fortunately, I don't need your or your Professor's approval, nor anything > written in a text book, in order to make money with it. > > No problem. Huh! ... "differ ... over interpretation of some aspects"? It's more on the order of I can not find any commonality between the OO paradigm and The Dashwood Paradigm, except the use of an OOPL. I do, however, find a lot of commonality between The Dashwood Paradigm and "procedure-based, bottom-up design, with an OOPL"; and I rather like that; but to call this "OO paradigm" is just plain wrong. Consider that bottom-up design in procedural programming (not to be confused with the procedural paradigm) may be used to develop reusable components; but sometimes such components do not have a good fit. Using inheritance in an OOPL to correct for that makes it better fit; but using inheritance in this manner is not consistent with OOD. It is not the Professors who are mistaken about what OO is! <G>
From: Pete Dashwood on 4 Apr 2008 06:37
"Rick Smith" <ricksmith(a)mfi.net> wrote in message news:L9ydncNEK_U0YGjanZ2dnUVZ_ternZ2d(a)mid-floridainternet... > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:65lo9dF2gqp30U1(a)mid.individual.net... >> >> >> "Rick Smith" <ricksmith(a)mfi.net> wrote in message >> news:l6KdnaVTeOZ762janZ2dnUVZ_rSrnZ2d(a)mid-floridainternet... >> > >> > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message >> > news:65k1fkF2gdg4dU1(a)mid.individual.net... >> >> >> >> >> >> "Rick Smith" <ricksmith(a)mfi.net> wrote in message >> >> news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d(a)mid-floridainternet... >> >> > >> >> > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in >> >> > message >> >> > news:65fmhdF2fbsenU1(a)mid.individual.net... >> >> > [snip] >> >> >> To modify existing functionality does NOT mean modifying a base > class. >> > It >> >> >> means extending (through inheritance) or over-riding existing >> > behaviours. >> >> > >> >> > The priniples of object-oriented design do not include >> >> > the use of inheritance to overcome inadequate or faulty >> >> > design. In such cases, modifying a base class may be >> >> > unavoidable. >> >> >> >> I have never encountered such a situation and do not expect to. (Guess > my >> >> designs are not "inadequate" or "faulty"...:-)) >> >> >> >> I really don't care about academic "principles of OO design" unless > they >> > are >> >> pertinent to the world in which I live and work; your statement above > is >> >> not. >> >> >> >> My own principles (derived from over a decade of real world use) tell > me >> > not >> >> to modify a Base Class. >> >> >> >> So I don't. >> > >> > Therein lies the problem, Mr Dashwood! While you advocate >> > the OO paradigm, you don't actually use it--preferring your own >> > principles to those of the paradigm. <g> >> >> And how is having things work properly, a "problem"? >> >> I use the OO paradigm, I may differ with you over interpretation of some >> aspects of it. >> >> Fortunately, I don't need your or your Professor's approval, nor anything >> written in a text book, in order to make money with it. >> >> No problem. > > Huh! ... "differ ... over interpretation of some aspects"? > It's more on the order of I can not find any commonality > between the OO paradigm and The Dashwood Paradigm, > except the use of an OOPL. I do, however, find a lot of > commonality between The Dashwood Paradigm and > "procedure-based, bottom-up design, with an OOPL"; You have no idea of how I design stuff or the modelling processes I use. It is NOT procedural, it is totally Object based. It cannot be "bottom up design" when it is approached from a top down perspective. It is not about OOPL it is about a holistic approach which only recognises Classes and Objects at a conceptual AND a programming level. > and I rather like that; but to call this "OO paradigm" is > just plain wrong. OK, I won't call it that if it offends you. I really don't care... :-) > > Consider that bottom-up design in procedural programming > (not to be confused with the procedural paradigm) may be > used to develop reusable components; but sometimes such > components do not have a good fit. Using inheritance in an > OOPL to correct for that makes it better fit; but using > inheritance in this manner is not consistent with OOD. And we already established that I don't do that so what are you arguing about? (The only point of issue here is your statement that sometimes Base Classes HAVE to be amended. I disagree, (I'd rather scrap a base class and rewrite it than amend it; I DON'T use inheritance to fix flaws in the Class and would never do that), and suddenly, according to you (an expert in procedural COBOL...) I don't understand OO...? Have I ever claimed my approach uses OOD in a formal way? No. I certainly design around Objects (more correctly Classes...) but I have never claimed I am implementing formal OOD. I use Use Case modelling and paper models (along with a number of other approaches if the situation warrants it) and I derive Objects with behaviours and properties from that. I really don't care what you call it, but it certainly isn't procedural. This is just silly and unless you can show some reasonable basis for disagreeing, I won't be responding. A pedantic argumernt based on your understanding of what you THINK I do, is going nowhere for either of us. Pete. -- "I used to write COBOL...now I can do anything." |