Interesting take on Paradigms (OO vs Procedural)
in [Cobol]
|
From: Pete Dashwood on 13 Apr 2008 23:34 "Rick Smith" <ricksmith(a)mfi.net> wrote in message news:FcednQcQ9YCRWZ_VnZ2dnUVZ_h6hnZ2d(a)mid-floridainternet... > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:66durcFk6oreU1(a)mid.individual.net... > > [snip] > >> OK, I read your response and thought about it. >> >> I can see that it may be impossible for us to communicate on objects > because >> we have different intentions and different world views. >> >> I believe you are sincere and not doing it out of mischief so I'll stay > with >> it for now. >> >> You have stated elsewhere that you don't like the use of the word > "object", >> but that is what is used, and it can have different meanings depending on >> the context. >> >> I gave some thought to why the use of "object" should be so troublesome > (at >> least for you and me...) >> >> I use "object" in a broader sense than you do (except when I don't...:-)) >> and, as you are not interested in the overall concept I am trying to > express >> (and, I might add it is extremely difficult for me to express something > that >> is a purely conceptual abstraction, despite normally having little >> difficulty expressing my thoughts) you seized on what I wrote and >> attacked >> it >> because it doesn't match your definition. It's like you make no attempt > to >> see what I am trying to say, and are more interested in a hair splitting >> argument about it on grounds I have no intention of discussing, let alone >> defending. >> >> During this discussion I have sometimes used "object" in a much broader >> sense than merely "an instance of a Class". >> >> Peter Coad (Coad/Yourdon) gives some good advice on what he calls "Object >> think"... and I believe this is the basic fundamental way of looking at >> objects which I absorbed many years ago and still operate upon. For me > now, >> it is "taken as read" and I am usually communicating with others who >> understand this definition also, so no problem arises. On the fairly rare >> occasions when I am discussing an object as being computer code > representing >> an instance of a class, I believe that is pretty obvious from the >> context, >> but it may not be. >> >> Coad views each object as knowing things and knowing how to do things; >> whether you agree with it or not, it will at least help to clarify for >> you >> how I see it... >> >> When modelling with objects (or even generally thinking about them) I >> tend >> to personalize them, so... >> >> I am a Customer. >> I know my: >> name >> address >> phone number >> date of birth >> I know how to: >> display my details on various devices and media >> update my details >> create a new instance of myself >> cancel my account >> create a new account for myself >> display details of any account I hold >> get a balance of any account I hold >> >> This is a long way from COBOL 68 :-) >> >> You can see that this kind of view is quite distant from the formalism of >> OOA, OOD, OOP although it can certainly be applied there also. >> >> I think that an article I read back in the early days (around 10 years >> ago...) makes an accurate statement of some of the problems being >> encountered here... >> >> The following is extracted from one small part of it: >> >> "The Problem of Adults Learning New Concepts >> >> Business engineering teams are increasingly turning to object-oriented >> techniques to model business processes. In the future, the business model >> and the software model will become fused. Both business and computing >> professionals must learn to "object think" in order to gain the knowledge >> and skills needed for business reengineering. However, since object >> orientation involves a paradigm shift, the principles of adult learning > must >> be carefully applied. One mainframe programmer (quoted from an article in >> Computerworld March 14, 1994) who made the transition to objects, > described >> the essence of the new way of thinking: "In any kind of procedural > language, >> you are breaking down work flow and coding it. In object-oriented design, >> you're breaking down events and assigning responsibilities to *OBJECTS* > and >> not really dealing with work flow anymore." Once the new way of thinking > is >> instilled, the syntax, grammar and complexities of object-oriented tools > and >> techniques become manageable to the learner. " >> >> (My emphasis...) >> >> I don't know if any of this helps at all, but this is my best shot at >> explaining what I mean (usually) when I use the term "object". > > Some of the difficulties I have with the term "object-oriented" > are addressed in a blog by Chuck Hoffman titled, "conventional > OO syntax considered <strike>harmful</strike> needlessly > misleading", January 9, 2008. > < http://nothinghappens.net/?p=214 > > > < http://en.wikipedia.org/wiki/Class-based_programming > > describes an "object" similar to the way I have understood it > to be, with additions I hadn't thought about at all.. > ----- > An object is similar to a structure, with the addition of method > pointers, member access control, and an implicit data member > which locates instances of the class (i.e. actual objects of that > class) in the class hierarchy (essential for runtime inheritance > features). > ----- > > I find no immediate connection between this or other > formal definitions of "object" and the identification of > objects during the earlier phases of analysis and design; > however, these phases together with programming may > be (and in my case are) connected by "class". > > At least eight years ago, I made a mental shift from > "object-oriented" to what is now called "class-oriented" > and, once I did that, the benefits and problems of using > object-oriented techniques became clearer. > > I have no reason to doubt that "object" was clear in > Dr. Kay's mind when he coined the term "object-oriented"; > but that same clarity has eluded me. Even today, "object" > in "object-oriented" seems contrived, rather that natural; > especially in contrast to "procedure" in "procedural". > "Encapsulation-oriented" might be a better term than > "object-oriented". > > "Alan Kay is often quoted as having said that, in retrospect, > he would have called it 'message oriented' rather than > 'object oriented'." -- < http://nothinghappens.net/?p=214 > > > However, I find "class-oriented" to be just fine. > > My experience, for more than twenty years, was with a > company that produces both hardware and software. > Embedded systems and stand-alone software are two > places where object-oriented (or class-oriented) is > an excellent fit. This is, therefore, the point of view from > which I studied object-orientation. From this perspective, > the goal was, as I saw it, to create separate, reusable, > application-centric class structures, similar in form to > Microsoft's Foundation Classes and, from those class > structures embedded programs and stand-alone > applications. > > Admittedly, this is probably not the best frame of mind > for learning about shape objects, ball objects bouncing, > or velociraptor objects chasing, pouncing on, and eating > prey objects. While I don't know how my transition > occurred, I imagine the mention of object and seeing a > class may have equated the two and led me to think about > class only. Once I made the transition, object became > rather meaningless and I was free to learn what I needed. > An interesting post and POV. Thanks for that, Rick. Pete. -- "I used to write COBOL...now I can do anything." >
From: Rick Smith on 13 Apr 2008 23:47 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:66g1mrF2kalcvU1(a)mid.individual.net... [snip] > An interesting post and POV. > > Thanks for that, Rick. You are welcome.
From: William M. Klein on 14 Apr 2008 10:24 <previous info deleted> some of this thread reminds me of one of my (many) lost battlers during the development of the '02 COBOL standard. I never liked the implications of the syntax Invoke object-reference "method-name" using passed-parameters It always seemed to me that what was really happening was that a "message" was being sent to the object-reference to be processed BY "method-name" using passed-parameters. or in pseudo-syntax Send Message to object-reference for "method-name" using passed-parameters I can't think of any other case in which two "operands" follow a COBOL statement name before a preposition where the two have "different" uses, e.g. Compute filed-1 field-2 = arithmetic expression In this case, "field-1" and field-2 are simply repeated receiving operands. I didn't even think that object-reference is the "object of the verb" INVOKE (English grammar, not "object" in OO sense) Are you really "invoking" an object reference? or are you sending something to it? Oh well, it is certainly too late now, but I this thread did remind me of the old issue. -- Bill Klein wmklein <at> ix.netcom.com
From: Rick Smith on 14 Apr 2008 13:40 "Charles Hottel" <chottel(a)earthlink.net> wrote in message news:AtCdnRqpKKdHQp3VnZ2dnUVZ_gudnZ2d(a)earthlink.com... [snip] > I think you can make a case to prefer "class based programming" to "object > oriented programming" but the hard facts of reality are that that ship has > sailed. It seems I found another ship!
From: Frank Swarbrick on 14 Apr 2008 20:10
>>> On 4/14/2008 at 8:24 AM, in message <3OJMj.441909$us.6638(a)fe04.news.easynews.com>, William M. Klein<wmklein(a)nospam.netcom.com> wrote: <> previous info deleted> > > some of this thread reminds me of one of my (many) lost battlers during > the > development of the '02 COBOL standard. > > I never liked the implications of the syntax > > Invoke object-reference "method-name" using passed-parameters > > It always seemed to me that what was really happening was that a > "message" was > being sent to the object-reference to be processed BY "method-name" using > passed-parameters. or in pseudo-syntax > > Send Message to object-reference for "method-name" using passed-parameters Seems to me that you'd really want: Send Message "method-name" to object-reference using passed-parameters or just Send "method-name" to object-reference using passed-parameters The problem with that being that you now have the verb first and the subject (object?) second. Personally I prefer that in many ways, but it would make auto-complete rather difficult, I think. Frank |