adamj@thoth17.berkeley.edu.BERKELEY.EDU (10/24/87)
In article <1691@culdev1.UUCP> drw@culdev1.UUCP (Dale Worley) writes: >Another feature of "software ICs" comes from the fact that they are >part of an object-oriented system. One can actually write, say, a >linked list manager that will work on objects of *any* type. In most >languages, this is impossible to do in a library routine. "Object oriented?" What you are describing involves parameteized typing and polymorphic routines. Objected oriented programming (in my book) involves data hiding and polymorphic routines. Parameterized typing is an independent concept from data hiding. Parameterized typing should be a tremendous win because it then becomes possible to change the lower levels of a hierarchical type without affecting the routines that only need to know some overall information about that type. I'd like to drop the term "software IC" as that an IC is noticibly deficient in this low-level parameterization. E.g., I can't buy a TTL IC from Radio Shack, buy a GaAs description module, apply one to the other, and get my favorite chip design in GaAs. The chip design has to be reworked by the manufacturer, just like present day software has to be recompiled and probably edited by an owner of the source code. >I suspect that I could write considerably less code if I could write >in one statement all the trivial, but extremely stereotyped, bits of >code. After all, what fraction of your lines of code are >loop-and-search, and other completely standard stuff? >Dale Right on! --Adam J. Richter adamj@widow.berkeley.edu ...!ucbvax!widow!adamj Adam J. Richter adamj@widow.berkeley.edu ....!ucbvax!widow!adamj (415)642-7762
chip@ateng.UUCP (Chip Salzenberg) (10/26/87)
In article <5606@jade.BERKELEY.EDU> adamj@widow.berkeley.edu (Adam J. Richter) writes: >In article <1691@culdev1.UUCP> drw@culdev1.UUCP (Dale Worley) writes: >>Another feature of "software ICs" comes from the fact that they are >>part of an object-oriented system. One can actually write, say, a >>linked list manager that will work on objects of *any* type. > > "Object oriented?" What you are describing involves >parameteized typing and polymorphic routines. Not so. Objective-C supports _heterogoneous_ collections. For example, a single Set can hold another Set, a Dictionary, an Array, and any number of other types -- _simultaneously_. -- Chip Salzenberg "chip@ateng.UUCP" or "{uunet,usfvax2}!ateng!chip" A.T. Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding. I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK
ben@hpldola.HP.COM (Benjamin Ellsworth) (10/28/87)
> Not so. Objective-C supports _heterogoneous_ collections. For example, a > single Set can hold another Set, a Dictionary, an Array, and any number of > other types -- _simultaneously_. Firstly: Objective C?!! YUCHHHHH!!!! In my opinion it is the product of a brain-damaged biologist. You are certainly free to disagree, however, look at Small-talk and C++ before you religiously defend "Objectionable C." Secondly: Just because a language says that it is "object oriented" doesn't mean that the concepts mentioned are not distinct. The facility is handy and hence included in the language constructs. It is not a neccessary part of an object oriented approach. ----- Benjamin Ellsworth ...hplabs!hpldola!ben
drw@culdev1.UUCP (10/28/87)
chip@ateng.UUCP (Chip Salzenberg) writes: | Objective-C supports _heterogoneous_ collections. For example, a | single Set can hold another Set, a Dictionary, an Array, and any number of | other types -- _simultaneously_. The other important feature that object-oriented systems need (Objective-C has it, I don't know of C++ does) is that one can build two objects that present the same external interface, but for which the method-routines are different. I.e., I can have two different sorts of "dictionary", implemented differently, and the code that uses them can't tell the difference between them. (This is why you need run-time mapping from method-names to routines.) Dale -- Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw If you get fed twice a day, how bad can life be?
arny@wayback.UUCP (Arny B. Engelson) (11/12/87)
In article <1716@culdev1.UUCP>, drw@culdev1.UUCP (Dale Worley) writes: > The other important feature that object-oriented systems need > (Objective-C has it, I don't know of C++ does) is that one can build > two objects that present the same external interface, but for which > the method-routines are different. I.e., I can have two different > sorts of "dictionary", implemented differently, and the code that uses > them can't tell the difference between them. (This is why you need > run-time mapping from method-names to routines.) This concept is also present in Ada. The implementation of an object (such as a queue, stack, or anything else) is separated from its external interface. Combine this with generics and overloading and you can create a pretty flexible library of "objects".
drw@culdev1.UUCP (Dale Worley) (11/17/87)
arny@wayback.UUCP (Arny B. Engelson) writes: | In article <1716@culdev1.UUCP>, drw@culdev1.UUCP (Dale Worley) writes: | > The other important feature that object-oriented systems need | > (Objective-C has it, I don't know of C++ does) is that one can build | > two objects that present the same external interface, but for which | > the method-routines are different. | This concept is also present in Ada. The implementation of an object | (such as a queue, stack, or anything else) is separated from its external | interface. Combine this with generics and overloading and you can create | a pretty flexible library of "objects". True, but in Ada, the compiler has to be able to figure out which implementation of a given abstract object is being dealt with. In object-oriented languages, this only has to be determinable at runtime. Dale -- Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw If you get fed twice a day, how bad can life be?