From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,47def5aa7b3182bd X-Google-Attributes: gid103376,public From: Samuel Mize Subject: Re: (shorter and new) programming by extension Date: 1999/02/26 Message-ID: <7b6gh6$20in@news1.newsguy.com>#1/1 X-Deja-AN: 448769671 References: <79fct8$9k3$1@murdoch.acc.Virginia.EDU> <1103_918264881@DZOG-CHEN> <36cdb012.580716@news.pacbell.net> <7av52o$62g@news3.newsguy.com> <7avc0i$cnb$1@its.hooked.net> <7b1kdb$13k6@news3.newsguy.com> <7b22f5$1mrg@news1.newsguy.com> <7b49mm$t7q@news1.newsguy.com> <7b4oa7$8pj$1@its.hooked.net> Organization: ImagiNet Communications, Ltd. User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2) Newsgroups: comp.lang.ada Date: 1999-02-26T00:00:00+00:00 List-Id: Mike Silva wrote: > > Samuel Mize wrote in message <7b49mm$t7q@news1.newsguy.com>... >>I'm too pedantic to leave adequate-enough alone, so I've refined my >>example of non-object-oriented programming by extension. I integrated >>that into the text I wrote on that earlier. I hope somebody out there >>finds this of interest. > > > Thank you very much for your explanations, Sam. I gather (though I haven't > read your last message through yet) that programming by extension is > essentially the mechanics part of OOP, without the data and methods > organization part (which I gather is best expressed in Ada using the package > concept). I hope I've got that right, since I feel like I've had a major > "oh yeah!" breakthrough. Well, your new insight is probably pointed in the right direction, but I can't agree with your phrasing. For an initial insight, though, you're doing very well. > programming by extension is > essentially the mechanics part of OOP, without the data and methods > organization part In a larger sense, it's any technology that lets you extend the capabilities of a system by linking in new code, without having to go in and recode or recompile the existing stuff to integrate it in. The specific examples I've show use Ada 95's polymorphic subprograms to do this. Polymorphism is one mechanism that goes into OOP. But it isn't ALL of the "mechanics part of OOP," and it isn't the only possible approach to "programming by extension." For instance, many Lisp environments take an extremely flexible view of function definition and linkage, and it's normal to build up a program piecemeal. Many of the techniques used in that kind of "rapid prototyping" can be legitimately called "programming by extension." Object-oriented folks like to say that the three touchstones of OO methods are: abstraction, encapsulation, and inheritance. I think it's fair to say that they are talking about abstraction in terms of objects; functional abstractions, or data-flow abstractions, aren't object-oriented. - The non-object-oriented programming by extension that I demonstrated uses a purely functional kind of abstraction. - It doesn't require any encapsulation of data -- all the records may well be publicly visible, and changed arbitrarily by any part of the rest of the system. - While inheritance of functions is used, there is no general inheritance of data structures. So, it fails all three mechanical tests for object-orientation. Furthermore, there is no attempt to create a hierarchy of classes that define the essential abstractions that organize the system. This is the philosophical heart of object-oriented methods. > the mechanics part of OOP, without the data and methods > organization part (which I gather is best expressed in Ada using the package > concept). Well, I'd identify two issues here: - encapsulation (preventing anything but the object's methods from operating on its data) - organization (pulling together all and only the stuff related to the class, for clarity) For any type, not just tagged types, encapsulation is enforced with the package mechanism, but ONLY if you make the type private. So it's really an interaction between typing and packaging. Organization may use packaging, as well as the ordering of the code, naming conventions, and so on. Now, if you want to get a "class" in the style of C++, you will want to define a package that contains only the tagged type with its operations and support items (like constants). But you should be aware that this is only one kind of object-oriented coding. Ada supports a number of other paradigms. Some people will argue violently, even rudely, that that is a very poor kind of object-oriented technology. Because Ada 95 only provides the building blocks, you can do whatever kind of object-oriented development you want. And, you can do other things with those building blocks (like non-object-oriented programming by extension). Best, Sam Mize -- Samuel Mize -- smize@imagin.net (home email) -- Team Ada Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam