jeff@aiai.ed.ac.uk (Jeff Dalton) (10/11/89)
I suspect that one reason for all the confusion and for all the dogmatic definitions of "object-oriented" is some people will claim almost anything is object-oriented. In a sense, they're right, because you can "think objects" in almost any language. But once someone says Ada is object-oriented because it has overloading, just for example, someone else will come up with a definition that rules out overloading as having anything to to with OOP.
merlyn@iwarp.intel.com (Randal Schwartz) (10/17/89)
In article <1208@skye.ed.ac.uk>, jeff@aiai (Jeff Dalton) writes: | I suspect that one reason for all the confusion and for all the | dogmatic definitions of "object-oriented" is some people will | claim almost anything is object-oriented. In a sense, they're | right, because you can "think objects" in almost any language. | But once someone says Ada is object-oriented because it has | overloading, just for example, someone else will come up with | a definition that rules out overloading as having anything to | to with OOP. Is this a comment about people's religious views of what it means to be "object-oriented", or about Ada in particular? :-) If the second, I'll throw in... "Ada is PL/1 trying to be Smalltalk" (no flames back please... either like it, or don't! :-) Just another SmallTalker, stuck in this UNIX-compatible world... -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
sakkinen@tukki.jyu.fi (Markku Sakkinen) (10/17/89)
In article <5065@omepd.UUCP> merlyn@iwarp.intel.com (Randal Schwartz) writes: >[...] >"Ada is PL/1 trying to be Smalltalk" > >(no flames back please... either like it, or don't! :-) No flame, just some education: Ada's basic design and philosophy is clearly different from the "featurism" of PL/1 (while even PL/1 was in many ways an admirable effort for its time). Ada tries least of all to be Smalltalk: it is just as unfit for very dynamic "exploratory programming" as Smalltalk is unfit for programming embedded real-time systems for space flight. A little aside: do we object-orienters tend to be some kind of Stalinists, always looking out for "class enemies" like Ada and COBOL to liquidate? Have our own languages and systems not enough merit, so we must scorn others? (I think Ed Berard wrote about this in his recent report on OOPSLA'89.) >Just another SmallTalker, stuck in this UNIX-compatible world... >[...] Dispair not, you can already have Smalltalk on many of those UNIX-compatibles. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
kannan@babcock.cerc.wvu.wvnet.edu (R. Kannan) (10/18/89)
This is a learners understanding of Objects in general: Well we really have to look back. ASSEMBLY LANGUAGE:( I have intenionally left out all means of comm. and related developements that occured before computers) Motivated to avoid coding in bit streams. In the beginning it must have craeted same commotion as does Objects now. Then people mastered it and wanted more power. Assembler does the job of converting Mnemonics to the bit streams that the machine can deal with. Languages: Higher Level Programming Fortrans or Basic is more fun and productive than menmonics. System guys, bear with me, please. Rather ignore me. Dont get worked up, BTW, what are you doing reading Object highest order in ABSTRACTION spectrum. For example: Organizing a Relational DBMS using Fortran would be something, I would never dream off. DATA STRUCTUTERS: PL/I and its class. Specials like APL. But the main point all of these have been a step toward more complex concepts, but less work. For example X = Y. The programmer has to accept the underlying concepts (types, precedence lvalue, rvalue, constraints all the goody goodies) and consequently not worry about MOVELONG instruction. The compiler and linker do the needful, to go bit streams. Oh yes, I can deal with RDBM with these tools. PL/I(compilers, etc) is a tool to do what I want more efficiently, understandably, easily with less pain and agony. I still have to deal with the integrity of the data structures, what can be done to them and what cannot be done to them etc. What is the next step. Naturally more complex, OBJECTS. DATA TYPES : Ada and some other languages that set the tone. Provide some integrity. Ada packaging does limit what the user can do to a certain type, but IMHO, Ada is not OO. Ada aides OOP more than many other languages. Now I can deal with a type window and deal with x,y coordinate. Still we need to deal with x,y and underlying semantics of the window. OBJECTS: Conceptually more associations (than an integer variable in Fortran.) And more levels of association. To elaborate, integer variable: ASSOCIATION DIRECT -> a value, IMPLICIT -> a type IMPLICIT -> an address IMPLICIT -> scope of the variable EXPLICIT -> symbol. An object: EXPLICIT -> symbol. EXPLICIT -> A collection of properties, slots, value holders. And each slot may have any number of values and the type are associated with each value. EXPLICIT -> Methods. EXPLICIT -> Relationship with other objects. Implicit -> there are mnany. Objects: behavior, class, named properties etc. Really an integer is an object which has one nameless property, which is its current value, belongs to the class integer. Behaves as dictated by the overloaded math operators in a programming language. Implementation point of view is a data structure with function pointers and indirections to other Objects. Objects have an internal defintions of what they depict in the real world(See we have started talking about internal and external, there has always been one, but here it is conceptual, not like the internal byte ordering or representation ). A set of activities go with the objects. And a system maintains or enforces the integrity among the objects. Really handling windows becomes easy. I have one prototype how most windows should behave, what each should old etc. I just create more as and when I need. Underlying mechanism deals with the complexity. Ever recall asking for n bytes (4 or 2) for an integer. Here we are talking more than bytes. And the system remembers and manages the complexity for us. We worry about higher level details. We get more work done. Thus Objects are just a point in Human evoultionary process. I have started on what could be more useful than Objects. But I dont have the vision that the guys who thought of Objects had. I am still in the same plane. This is simple first cut at what I understand about why? what? of an object without much of the technical details.
fargo@pawl.rpi.edu (Irwin M. Fargo) (02/12/90)
As someone who has been using Smalltalk/V 286 and has gotten an extremely good grasp of OOP, I'd be interested in hearing what other OOP people think OOP really is. My mentor when learning Smalltalk said that there are a few things that make a language object oriented. He said they were: encapsulated objects message selectors and methods classes a class hierarchy Do you think it makes sense to try and quantify OOP in this manner? If so, what ideas do you think make a language an OOPL? I really would appreciate responses to this as I'm looking into some OOPL design and would like some pointers. Thanks. -- Thank you and happy hunting! Actually: Ethan M. Young ____ [> SB <] "Travel IS life" Internet: fargo@pawl.rpi.edu /__ -=>??<=- - Irwin M. Fargo Bitnet (??): usergac0@rpitsmts.bitnet / ARGO : 3000 years of regression from the year 4990
zweig@brutus.cs.uiuc.edu (Johnny Zweig) (02/13/90)
I think it is important to distinguish Object-Oriented Programming in the
definitive sense from what O-O programmers do when they get to work every
day. OOP means organizing software in a natural way that consists of objects
performing operations on one-another (as opposed to functions that operate
on more loosely-structured data). This means that classes exist -- but does
not mean (IMHO) that you need class-hierarchies or types. Consider a
delegation-based language: everyone who delegates to object Foo can be
considered to be a member of a class (to wit: the class of all objects that
are similar enough that I make them all delegate to Foo). I think you need
some notion of class to even be able to talk about an object-oriented
program -- if I have a bunch of objects, I need to be able to describe (at
least to another human; the code need not embody this knowledge) what _kind_
of object each one is, and what it's _for_.
I think class-hierarchies, inheritance and typing (ignore that last one all
you SmallTalkers) come pretty naturally once you commit yourself to making a
program that consists of objects. It comes under the "what you do when you
get to work" part of it -- nobody would use an O-O language without some way
of reusing behavior (inheritance/delegation) if they were doing OOP and had
any way of getting away with using one that does (note the subtle Ada-bashing
in there). The stuff people argue about ("tastes classy!" vs. "less typing!")
is really not part of "what OOP is" rather, it is part of "how I like to do
OOP".
-Johnny Distinctionjimad@microsoft.UUCP (JAMES ADCOCK) (02/14/90)
In article <+B8|X-@rpi.edu> fargo@pawl.rpi.edu (Irwin M. Fargo) writes: ... >encapsulated objects If you seriously look at any "object oriented" code, you will discover that encapsulation is not an important criterion in presently programmed OOP code. I'd claim inheritence is antagonistic to encapsulation. Not to imply we shouldn't be using inheritence, nor that we shouldn't be better encapsulating. Just that "we" aren't. >message selectors and methods "Message selectors" and "methods" are Smalltalk-ese. Other OOPLs use other terminology for techniques spanning the whole range of speed verses flexibility trade-offs. And more modern optimizing OOPL compilers make many of these trade-offs too, regardless of the terminology called out in the language manual. >classes "Self" being an interesting example of an OOPL without classes. >a class hierarchy Ditto. >Do you think it makes sense to try and quantify OOP in this manner? If so, >what ideas do you think make a language an OOPL? I don't think it makes any more sense to try to quantify OOP than it makes sense to quantify the "structured methodology"-nese or "top-down"-edness of a design. Given that OOP is good, everything must be OOP, [whether it is, or not] My claim is that in less than five years *everything* is going to be "object oriented." More sensibly, I think there are some reasonable distinctions that can be made. "Class-oriented" programming of Smalltalk verses "Object-oriented" programming of Self. [I'd claim the widely used "object oriented" is a misnomer for what is actually "class-oriented".] Delegation verses inheritence. Single verses multiple inheritence. Strict verses non-strict typing. Distinctions based on method dispatch methodology are increasingly non-sensical as we head towards good optimizing compilers.