dsill@ark1.nswc.navy.mil (Dave Sill) (10/25/89)
Is it just me, or does anyone else find disturbing the number queries of the form: Does anyone know anything about object-oriented <Topic>? Where recent instantiations of <Topic> include: analysis design parsers security testing Is object orientation such a novel approach that we'll have to relearn everything we've already figured out? If so, is it really worth the effort? Admittedly, I'm an object-oriented novice. I've read various object-oriented articles in Byte and Computer Language, and I even took a one-day tutorial in C++ at USENIX. But I've never written an object-oriented program, and it isn't obvious to me what makes object-orientation so profoundly different, and presumably, better. Dave Sill (dsill@relay.nswc.navy.mil)
hallett@pet3.uucp (Jeff Hallett x5163 ) (10/26/89)
In article <190@ark1.nswc.navy.mil> Dave Sill <dsill@relay.nswc.navy.mil> writes: >Is object orientation such a novel approach that we'll have to relearn >everything we've already figured out? If so, is it really worth the >effort? Interesting question. The answer is, sometimes. The object-oriented paradigm basically groups data into classes and assigns class methods that they may use to manipulate that data and communicate with the rest of the world (yeah, its loose, but shut up :^) The concept is not really so revolutionary, but the true object-oriented systems add a lot that ordinary procedural systems cannot have. However, even procedural systems can benefit from object-oriented analysis even if the program is not implemented in an object-oriented language. An object-oriented design is a design that naturally grows from performing the analysis - from the procedural standpoint, such a design is only useful if it best addresses the problem. On the other hand, it is quite in vogue to throw "object-oriented" in front of some normal term and get a great new buzzword or show off in front of your friends. IMHO, "object-oriented security" is just such a term. Always keep one thing in mind, object-oriented approaches are just really different ways of examining a problem. It provides a more data-driven view than standard, control-driven procedural methodologies. If the approach adds insight to your problem or significantly shows information about a problem not previously noted, then an object-oriented study of the problem may actually spawn a new topic of interest. Otherwise, it probably isn't worth your time. Only you can judge. -- Jeffrey A. Hallett, PET Software Engineering GE Medical Systems, W641, PO Box 414, Milwaukee, WI 53201 (414) 548-5163 : EMAIL - hallett@gemed.ge.com "Your logic was impeccable Captain. We are in grave danger."
anders@cui.unige.ch (BJORNERSTEDT Anders) (11/09/89)
In article <1959@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) SAKKINEN@FINJYU.bitnet (alternative) writes: >In article <984@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >-That doesn't help (does it?). A number languages have abstract data types, >-which have been around for longer than OOP. > >OOP began with Simula 67 around 1967, but Simula had no 'abstract data type' >concept (it has encapsulation facilities today). >Has there really been some programming language with ADT's before 1967? Yes. I think the simula-67 common base language definition already had the class concept, but not the HIDDEN & PROTECTED features. This means that you could construct and use ADT's using the class concept, but could not prevent other programmers from poking at internal representation. In fact the way I had understood the "history of concepts" is that the idea of ADT's emerged in the 70's and evolved (in part not entirely) from one way of using the simula class concept. The paper: B.H. Liskov and S. Zilles, "Programming with abstract data types," ACM SIGPLAN Notices, vol. 9, 1974. makes a REF to Simula. --------------------------------------------------------------------- Anders Bjornerstedt E-mail: anders@cuisun.unige.ch Centre Universitaire d'Informatique 12 rue du Lac, CH-1207 Geneva --------------------------------------------------------------------- Tel: 41 (22) 787.65.80-87 Fax: 41 (22) 735.39.05 Home: 41 (22) 735.00.03 Telex: 423 801 UNI CH ---------------------------------------------------------------------
nick@lfcs.ed.ac.uk (Nick Rothwell) (11/09/89)
In article <352@m1.cs.man.ac.uk>, mario@r3 writes: >1. No side effects? I defy you to show me a useful program that has > no side effects :-). More seriously, doesn't ML have a reference > type? Ok, what I said was actually inconsistent (too much typing with brain in neutral). In fact, ML allows you to build objects with state and hence functions with side-effects. In practice, the largest proportion of a program is purely functional with a few reference variables to tie things up at the top. I'm currently working on a 10000 line ML interpreter which has around a half-dozen references (one or two timestamp generators and a top-level variable to hold the environment between runs), everything else being purely applicative. Since assignment is only permitted for explicitly created reference objects (unlike a lot of LISPs), this seems a good compromise. >> (Both of these open the doors to computer-assisted reasoning >> about program correctness.) >So has Pascal. So has 6502 machine code. So what? What I should have said is something far less controversial... :-) because 99.9% of this ML program is side-effect free, it's quite easy to reason informally about what it does, since no component is holding any kind of hidden state - all the interfaces and functions can be trusted to do behave referentially transparently, and return results based only on their input values. I think that 100% applicative programs have difficulty dealing with the outside world (I/O and so on), and start to get rather contorted. >Hmm, I wonder what what these Smalltalk expressions are if not >functionals and generators ... > double := [ :f | [ :x | f value: (f value: x)]]. > someObscureCollection do: [ :each | each process ] I personally find a powerful type system (polymorphism, parameterised types, abstraction) to be pretty essential to make the most of higher-order functions, accumulating parameters, continuations and so on. I'll grant that other people (like the Scheme people) seem to have no problem programming "in the saddle", but that requires run-time debuggers and so on, and it's a different way of working. Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Fais que ton reve soit plus long que la nuit.
db@lfcs.ed.ac.uk (Dave Berry) (11/17/89)
Some of the claims made in this group for OO languages compared to other
languages seem a bit odd. For example, ADTs aren't only a feature of
OO languages. If Simula 67 is OO then there exists an OO language
that doesn't support ADTs.
Another example was a recent article saying that a queue ADT only had
to be implemented once. This is an example of polymorphism, which can
be implemented in several ways, many of which aren't OO. One example
that people pointed out was parameterised ADT's, These aren't a new
concept either.
I don't think that either OO or ADTS "came first" to programming languages.
ADT's and the other features of a modern OO language seem to be linked
strands of development of programming languages during the 70s.
As one strand of this development, ADTs (including parameterised ADTs) have
been used in several specification languages, such as CLEAR and ASL.
All this makes me wonder which "other languages" people are comparing OO
languages with. Perhaps if we were more specific in this respect we would
reach a clearer idea of which features are OO and which features are
related but useful.
(I would guess that this confusion arises because OO languages are the first
class of modern languages to make a big hit outside research labs, and
that a lot of people are only seeing these features for the first time
in OO languages. Which is another Good Thing about OO languages!)
My opinion is that the main feature of an OO language is that objects
contain information about their class. The effect of this is that we
can build collections of objects of different classes, call a member
function of an arbitrary object of that collection and get the correct
function for that class. In other words, dynamic binding of functions
(as opposed to dynamic binding of variables, as in old lisps).
Some people have said that objects contain their member functions. This
isn't true of any OO language I've seen. In these languages, classes
contain member functions and each object (intuitively) contains a pointer
to its class. If this seems nitpicking, consider the possibility of
an OO language with functions as values. In such a language member
functions would bear the same relation to function values as class
attributes to object attributes.
Inheritance and/or delegation are obviously important concepts too.
In a statically typed language, inheritance as subtyping is needed to
allow dynamic binding. In dynamically typed languages it doesn't
seem strictly necessary to me, and seems to be used more as a way
of reusing code (not that this isn't important). Ralph Johnson
mentioned some time ago that Emerald is an OO language without inheritance.
So my definition of an OO language would be
"classes + dynamic binding of functions".
with the footnote that inheritance is required for this in statically typed
languages and damn useful anyway in dynamically typed ones.
Of course, I'm probably wrong ...
Dave Berry, Laboratory for Foundations db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk
of Computer Science, Edinburgh Uni. <Atlantic Ocean>!mcvax!ukc!lfcs!dbpcg@emerald.cs.aber.ac.uk (Piercarlo Grandi) (11/18/89)
In article <352@m1.cs.man.ac.uk> mario@r3.cs.man.ac.uk writes: Piercarlo Grandi states: > 3) most FP languages have and emphasize functionals and generators > (non nested control flow), that make many complex program > structures much simpler, and they are not as used or available > (regrettably) in OO languages, and this accounts for *a lot* of > the difference (even if functionals and generators are not that > easy to formalize, let me observe :->). Hmm, I wonder what what these Smalltalk expressions are if not functionals and generators ... double := [ :f | [ :x | f value: (f value: x)]]. someObscureCollection do: [ :each | each process ] Oh yes, Smalltalk has some good support. But, but, of all people you are the one to know that blocks in Smalltalk have some disagreeable property that greatly limits their usefulness as closures/etc... And where is detach/resume? (well, in processes, but this seems a bit overdone). Anyhow, I could argue that any OOL with dynamic binding was using functionals all the time: every reference to an object also implicitly references its methods. Uhmmm. This is straining things a bit.... :-> Those who program in Smalltalk already use closures an awful lot, and even a form of continuation (albeit somewhat restricted) that to me is much nicer than than most mechanisms built into other languages for non-stack-based control flow. As to that, Simula 67 was *the* thing as to coroutines, generators, etc... (resume and detach); indeed I could argue that object oriented features were invented and added to Simula I/67 precisely because non nested flow control is essential to writing simulations. On the other hand, OO programmers in languages other than Simula 67 (and a few others, like in some way Smalltalk) do not have resume/detach, or are not familiar with funtionals. Too bad. It need not be the case. Well, I ten to agree that Smalltalk for one has nice FP like technology, no doubt inspired by Interlisp among others; but unfortunately Smalltalk is not what most people know as an OO language. The likes of Object Pascal, C++, Ada (argh!) are associated in the public's mind with OO programming. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
mario@r3.cs.man.ac.uk (11/21/89)
In article <PCG.89Nov18135245@emerald.cs.aber.ac.uk> Piercarlo Grandi writes: > Oh yes, Smalltalk has some good support. But, but, of all people > you are the one to know that blocks in Smalltalk have some > disagreeable property that greatly limits their usefulness as > closures/etc... And where is detach/resume? (well, in processes, > but this seems a bit overdone). All of the serious problems have been fixed in the 2.4 and 2.5 releases from ParcPlace. Blocks are now reentrant, can have their own temporaries, and access them through proper scoping mechanisms. Unfortunately, they are still not full continuations (this was probably asking a bit much), and the implementation of non-local returns is still not Blue Book, but on the other hand there is a Lisp-like dynamic-unwind available in 2.5. > Those who program in Smalltalk already use closures an awful > lot, and even a form of continuation (albeit somewhat restricted) > that to me is much nicer than than most mechanisms built into > other languages for non-stack-based control flow. > > As to that, Simula 67 was *the* thing as to coroutines, > generators, etc... (resume and detach); indeed I could argue that > object oriented features were invented and added to Simula I/67 > precisely because non nested flow control is essential to writing > simulations. Continuations are more powerful than coroutines; you can implement coroutines using continuations. The Blue Book semantics for blocks also allows you to do it (I can send you some example code if you want), but the ParcPlace implementations don't. I hope this will be fixed, and continuations added, in a Smalltalk-of-the-future. The following papers are recommended reading; they demonstrate the elegance and power of first-class continuations: @incollection{FriedmanHaynesKohlbecker84, author = "Daniel P. Friedman and Christopher T. Haynes and Eugene Kohlbecker", title = "Programming with Continuations", pages = "263-274", publisher = springer, year = 1984, volume = "F8", series = "NATO ASI Series", editor = "P. Pepper", booktitle = "Program Transformation and Programming Environments" } @article{HaynesFriedman87, author = "Christopher T. Haynes and Daniel P. Friedman", title = "Embedding Continuations in Procedural Objects", journal = toplas, volume = 9, number = 4, pages = "582-598", year = 1987, month = oct } @article{HaynesFriedmanWand86, author = "Chistopher T. Haynes and Daniel P. Friedman and Mitchell Wand", title = "Obtaining Coroutines with Continuations", journal = "Computer Languages", volume = 11, number = "3/4", pages = "143-153", year = "1986" } > Well, I ten to agree that Smalltalk for one has nice FP like > technology, no doubt inspired by Interlisp among others; but > unfortunately Smalltalk is not what most people know as an OO > language. The likes of Object Pascal, C++, Ada (argh!) are > associated in the public's mind with OO programming. And more's the pity. Mario Wolczko ______ Dept. of Computer Science Internet: mario@cs.man.ac.uk /~ ~\ The University USENET: mcvax!ukc!man.cs!mario ( __ ) Manchester M13 9PL JANET: mario@uk.ac.man.cs `-': :`-' U.K. Tel: +44-61-275 6146 (FAX: 6280) ____; ;_____________the mushroom project___________________________________
jtr@cs.exeter.ac.uk (Jason Trenouth) (11/25/89)
>>>>> On 7 Nov 89 04:34:51 GMT, weiner@novavax.UUCP (Bob Weiner) said: Bob> I would like to commend to anybody's attention BETA . . . Bob> Could anyone provide a short summary of BETA and its key innovations Bob> over other OOPLs? An description of BETA appears in: @InCollection{kristensen:beta, author = "B. B. Kristensen and O. L. Madsen and B. Moller-Pederson and K. Nygaard", title = "The {Beta} Programming Language", booktitle = "Research directions in object oriented programming", publisher = "MIT Press", year = "1987", editor = "B. Shriver and P. Wegner", } Its claim to fame is that it supports many diverse programming constructs with one underlying abstraction mechanism. Procedures, functions, data-types, classes, objects, etc are all implemented via something they call a _pattern_. Control and data structures are both defined using the same syntax. Very appealing idea and it might be a great boon to teaching programming. They also have something to say on the subject of concurrency. Borrowing a term from the other discussion, I believe that its a _non-orthogonal_ language. Hopefully someone who knows more about Beta will have posted by the time this reaches the net, but just in case! JT -- ______________________________________________________________________________ | Jason Trenouth, | JANET: jtr@uk.ac.exeter.cs | | Comp. Sci. Dept., Exeter Univ., | UUCP: jtr@expya.uucp | | Devon, EX4 4PT, UK. TEL: (0392) 264061 | BITNET: jtr%uk.ac.exeter.cs@ukacrl|
scc@cl.cam.ac.uk (Stephen Crawley) (11/27/89)
Dave Berry writes: [... stuff deleted ...] > My opinion is that the main feature of an OO language is that objects > contain information about their class. The effect of this is that we > can build collections of objects of different classes, call a member > function of an arbitrary object of that collection and get the correct > function for that class. In other words, dynamic binding of functions > (as opposed to dynamic binding of variables, as in old lisps). [...] > So my definition of an OO language would be > "classes + dynamic binding of functions". > with the footnote that inheritance is required for this in statically > typed languages and damn useful anyway in dynamically typed ones. GRRRR ... I wish people would stick to the well established definitions of terms like "object-oriented" and not go around inventing new & incompatible ones for no good reason! .. GRRRR Dave Berry is just plain wrong. First, inheritence does not give dynamic binding in a static language; inheritence + virtual operations gives dynamic binding! Second, Dave's new "definition" of OO excludes languages that are currently recognised as OO according to the accepted definitions. > Of course, I'm probably wrong ... You said it!!! -- Steve
sakkinen@tukki.jyu.fi (Markku Sakkinen) (11/27/89)
In article <1673@gannet.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: >Dave Berry writes: >[...] >> So my definition of an OO language would be >> "classes + dynamic binding of functions". >> with the footnote that inheritance is required for this in statically >> typed languages and damn useful anyway in dynamically typed ones. > >GRRRR ... > >I wish people would stick to the well established definitions of terms >like "object-oriented" and not go around inventing new & incompatible >ones for no good reason! > >.. GRRRR > "Well established" indeed! It looks to me that rather everybody who has published something on OOP has his/her definition (explicit or implicit) that is at least a little different from everybody else's. Of course, I have my own too. Peter Wegner's often-cited paper at OOPSLA'87 tries to define an "ascending sequence" of language categories: object-based, class-based (every object has a class), object-oriented (inheritance added). Dave Berry's definition is not so remote from this. On the other hand, there are people who argue that classes should be abolished in OOP! (Incidentally, they have not convinced me, but neither do I fully share Wegner's views.) Probably most people in this field will tolerate calling at least some classless languages, such as David Ungar's Self, "object-oriented". >[...] Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
nick@lfcs.ed.ac.uk (Nick Rothwell) (11/27/89)
In article <1673@gannet.cl.cam.ac.uk>, scc@cl (Stephen Crawley) writes: >I wish people would stick to the well established definitions of terms >like "object-oriented" and not go around inventing new & incompatible >ones for no good reason! Such as? I've seen no definition of "object oriented" which would rule out Dave's description above. I've read the first 5 or so chapters of Meyer's book, and everything he describes as characterising OO programming, and the benefits, applies equally well to the Standard ML Module system, which isn't object oriented (or is it?). >-- Steve Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ "You're gonna jump!?" "No, Al. I'm gonna FLY!"
scc@cl.cam.ac.uk (Stephen Crawley) (11/30/89)
> In article <1673@gannet.cl.cam.ac.uk>, I wrote: >> I wish people would stick to the well established definitions of terms >> like "object-oriented" and not go around inventing new & incompatible >> ones for no good reason! Nick Rothwell replied: > Such as Wegner's taxonomy for example. OK so he made some mistakes in his 1987 OOPSLA paper, but he has apparently fixed this in later versions of the taxonomy. At any rate it is a good place to start. I thought Modula-3 was a (Wegner) OO language that had no dynamic binding, but on reading the report, I find that I mis-remembered. ML would not recognised by many (most?) researchers as OO because does not have an inheritence mechanism. Me ... I don't think inheritence is such a great idea ... but I'm prepared to live with the accepted definitions ... so that we can put aside silly arguments about what OO means and talk about something useful. The only other sane alternative is for everyone to agree that OO means absolutely nothing, and invent a new bunch of words! Either way, new definitions of OO are counter-productive. -- Steve
db@lfcs.ed.ac.uk (Dave Berry) (11/30/89)
In article <1115@castle.ed.ac.uk> I wrote: >Some people have said that objects contain their member functions. This >isn't true of any OO language I've seen. In these languages, classes >contain member functions and each object (intuitively) contains a pointer >to its class. Some people have kindly pointed out that there are object oriented languages in which objects really do contain their member functions, e.g. Emerald, Display Postcript and (possibly) Self. Dave Berry, Laboratory for Foundations db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk of Computer Science, Edinburgh Uni. <Atlantic Ocean>!mcvax!ukc!lfcs!db "leIsANewEntertainment:GuerillaWarStruggleIsANewEntertainment:GuerillaWarStrug"
ewan@cs.washington.edu (Ewan Tempero) (12/01/89)
In article <1673@gannet.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: >Dave Berry writes: [... stuff deleted from both...] >> So my definition of an OO language would be >> "classes + dynamic binding of functions". >> with the footnote that inheritance is required for this in statically >> typed languages and damn useful anyway in dynamically typed ones. > >GRRRR ... > >I wish people would stick to the well established definitions of terms >like "object-oriented" and not go around inventing new & incompatible >ones for no good reason! While I tend to agree with this sentiment, I also think that the "established definition" of object-oriented is...misleading. Judging by what I read in the literature and in this newsgroup, most people think "object-oriented" means "has classes" and/or "has inheritence" (Wegner didn't help with his OPSLA'87 paper). Now, as definitions go, this would be perfectly acceptable if the same people didn't also think that if the language doesn't have these features then it isn't a good language (and can't have anything to do with objects) [yes I'm generalizing, but I've met this attitude often enough that it's worth discussing] So, let me say what features I think a "good language with objects" should have. I should warn you that all this is in terms of building and MAINTAINING large systems. (a) Ways to create objects (b) Ways to manage objects (c) no non-object constucts [ill-defined I know, maybe I'll say something later] Languages such as C++ and Smalltalk use classes for (a) and (b). C++ fails on (c) [someone claimed that instance variables in Smalltalk can be referred to directly in a "non-object" like manner..I wasn't sure what this meant exactly but if true then Smalltalk fails on (c) too] However classes are the only way to do things. You don't need a class to create objects--just provide an explict mechanism in the language (which I'll call an "object constructor") to do this. You don't need classes to manage the objects either. Afterall, what kind of management do you want? You basically just want to know what "kind" of object you've got and what you can do to it. A type system will do this just fine. Some people will argue that classes are just types. Well that's partially true, but many people think classes also provide code reuse and that's a completely separate mechanism. So I prefer to use "type" when I mean "describes behaviour" and "class" when I mean "describes implementation." If you're uncomfortable with the notion of a language with objects not providing code reuse [depending on what you mean by code reuse--I'm meaning the ability to take pieces of code already written and use them in building something new without using cut-and-paste in and editor] then see a paper by Raj and Levy in ECOOP'89, which describes how to do software reuse in a language-with-objects that is strongly-typed and doesn't have classes. --ewan
twl@brunix (Ted "Theodore" (W) Leung) (12/02/89)
In article <10013@june.cs.washington.edu> ewan@june.cs.washington.edu (Ewan Tempero) writes: > (a) Ways to create objects > (b) Ways to manage objects > (c) no non-object constucts [ill-defined I know, maybe I'll > say something later] So what makes a language that supports these features any different from a language that is based purely on abstract data types? In the absence of code-sharing/grouping mechanisms, what distinguishes an object from an ADT? This opens up the age old question of "what is an object", which will probably cause this group to go into conniptions. I don't think that labelling all the features with the right object-oriented whatever is what's needed. I think that we need to get good definitions of what the essential language elements are and try to understand their interactions in the language design space. -------------------------------------------------------------------- Internet/CSnet: twl@cs.brown.edu | Ted "Theodore" Leung BITNET: twl@BROWNCS.BITNET | Box 1910, Brown University UUCP: uunet!brunix!twl | Providence, RI 02912
ewan@cs.washington.edu (Ewan Tempero) (12/02/89)
-Ted >me In article <21986@brunix.UUCP>, twl@brunix (Ted "Theodore" (W) Leung) writes: -In article <10013@june.cs.washington.edu> ewan@june.cs.washington.edu -(Ewan Tempero) writes: -> (a) Ways to create objects -> (b) Ways to manage objects -> (c) no non-object constucts [ill-defined I know, maybe I'll -> say something later] -So what makes a language that supports these features any different -from a language that is based purely on abstract data types? This is a good question but I'm going to wimp out and not answer it directly (for now, anyway). My "definition" was only intended for a discussion on whether "classes" were required for OO languages, that is, it was to be taken in the context of OO languages only (afterall, I didn't define what an object was so that's the only context that makes sense...if sense is to be made from what I wrote). Which brings me to:- -In the -absence of code-sharing/grouping mechanisms, what distinguishes an -object from an ADT? The point I was trying to make, was that there is nothing inherent in objects that relates to code-sharing mechanisms. I read somewhere that it would be possible to put environment support on top of Modula-2 (or was it Ada?) that would allow things of the form NewModule.NewFunction = OldModule.OldFunction + stuff [this is very hazy and I don't have a reference for it. Does anyone?]. This is essentially what Simula does. As I have already said, there are languages that I think anyone would say provide objects and ways to manipulate them, but don't have code-sharing. They are also based purely on ADTs (so OO implies ADTs, at least). If you are going to insist that code-sharing mechanisms must be present then I think "object" is a misnomer. -This opens up the age old question of "what is an -object", which will probably cause this group to go into conniptions. :-) But if we can't discuss that here, where do we? :-) What I'm trying to do, is to answer exactly this question, without the baggage of code sharing (or concurrency, or anythings else). I think the concept of "object" exists independently and, once we have a better understanding of what this concept is, we can worry about the other stuff. -I don't think that labelling all the features with the right -object-oriented whatever is what's needed. I think that we need to -get good definitions of what the essential language elements are and -try to understand their interactions in the language design space. ...ahem. Yes, I agree. You said it better... --ewan
marc@dumbcat.UUCP (Marco S Hyman) (12/03/89)
In article <21986@brunix.UUCP> twl@boojum.UUCP (Ted "Theodore" (W) Leung) writes:
In the
absence of code-sharing/grouping mechanisms, what distinguishes an
object from an ADT? This opens up the age old question of "what is an
object", which will probably cause this group to go into conniptions.
Simple. An object is an ADT that has had its encapsulation broken by the
evils of inheritance.
// marc
(For the humor impared: This is a joke.)
--
// Marco S. Hyman {ames,pyramid,sun}!pacbell!dumbcat!marcbillwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/03/89)
From ewan@cs.washington.edu (Ewan Tempero): > The point I was trying to make, was that there is nothing inherent > in objects that relates to code-sharing mechanisms. I read somewhere > that it would be possible to put environment support on top of > Modula-2 (or was it Ada?) that would allow things of the form > NewModule.NewFunction = OldModule.OldFunction + stuff [this is very > hazy and I don't have a reference for it. Does anyone?]. There is a product called "Classic Ada" (available from Software Productivity Solutions, SPS@radc-softvax.arpa) which provides exactly this: it permits Ada software developers to use inheritance and dynamic binding in object-oriented Ada designs. The code produced is totally standardized, compile-it-anywhere, 100% portable Ada. A number of other vendors are jumping into this market as well, pending the inclusion of object-oriented facilities in Ada 9X. Bill Wolfe, wtwolfe@hubcap.clemson.edu
schaerer@unizh.UUCP (schaerer) (12/05/89)
References: <2426@umbc3.UMBC.EDU> <190@ark1.nswc.navy.mil> <1561@novavax.UUCP> <76915@linus.UUCP> <984@castle.ed.ac.uk> <1959@tukki.jyu.fi> <1115@castle.ed.ac.uk> <1673@gannet.cl.cam.ac.uk> <10013@june.cs.washington.edu> <21986@brunix.UUCP> <131@du
lsr@Apple.COM (Larry Rosenstein) (12/07/89)
In article <PCG.89Nov18135245@emerald.cs.aber.ac.uk> pcg@emerald.cs.aber.ac.uk (Piercarlo Grandi) writes: >unfortunately Smalltalk is not what most people know as an OO >language. The likes of Object Pascal, C++, Ada (argh!) are >associated in the public's mind with OO programming. This is sad but true. Although one must keep in mind that the use of the terms "most people" and "public" refer to the average computer user, and not people in CS departments, people who attend OOPSLA, etc. O-O languages were largely ignored in the popular computer press until Microsoft and Borland introduced versions of Object Pascal, and committed to supporting OOP in their environments. Since then there have been floods of articles about OOP in publications like InfoWorld, MacWorld, etc. At one would expect, a lot of these articles contain mis-information. For example in the Object Pascal competition between Microsoft and Borland, the press has portrayed Borland's language as "better" because they allow both virtual & non-virtual methods (a la C++). This is despite the fact that their language (in my opinion) is badly designed in places. On the bright side, this new interest in OOP leads to several funny articles and letter. In the June 19 InfoWorld is the following (shamelessly excerpted) letter to the editor. (As background, InfoWorld ran a series of aritcles about OOP, and this letter responds to one of them.) "First is concept of combining code and data into a single 'object.' Though I agree that this can simplify programming, the added overhead and duplication of code for each data object can vastly compound one of the most frustrating problems facing computer users today -- that of programs too big for available memory." [followed by a disussion of TSR's, "tight" coding, etc.] Of course, I'm being unfair to the writer of the article, because he later does make some valid points about discussing OOP separately from graphics interfaces. But it is humorous, nevertheless. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr