Rick DeNatale wrote: > On 10/17/06, Isaac Gouy <igouy / yahoo.com> wrote: > > > > Phrogz wrote: > > > Rick DeNatale wrote: > > > [snip] > > > > There's a famous story about a similar lecture he gave at Apple, where > > > > someone else pushed back in a similar way. If Oberon doesn't have > > > > encapsulation how can it be object-oriented. In this case, Wirth's > > > > ultimate rejoinder boiled down to "who can really say what > > > > object-oriented means." To which the questioner responded, "Well, I > > > > suppose I do, I'm Alan Kay and I invented the term." > > > [snip] > > > > > > The most authoritative-looking account[1] I could find say that it was > > > not Wirth giving the lecture (and that Alan didn't use his name in the > > > retort). Good story, though :) > > > > > > [1] http://c2.com/cgi/wiki?HeInventedTheTerm > > > > * "So, this product doesn't support inheritance, right?" > > "that's right" > > * "And it doesn't support polymorphism, right?" > > "that's right" > > * "And it doesn't support encapsulation, right?" > > "that's correct" > > * "So, it doesn't seem to me like it's object-oriented". > > > > That's just seems wrong. > > > > Here's a description of OBJECT-ORIENTED PROGRAMMING IN OBERON-2 > > http://www.statlab.uni-heidelberg.de/projects/oberon/kurs/www/Oberon2.OOP.html > > First, I don't know how accurately the description on Ward's Wiki > reflects what questions were actually asked of the presenter on > Oberon. > > More importantly though, note that it says that it was the original > Oberon, not Oberon 2. Since some language designers like to name > languages with version numbers, or dates, it's easy to confuse say > Oberon with Oberon 2, or Simula with Simula 67. That's timely - I was just about to make the same correction ;-) "One important goal for Oberon-2 was to make object-oriented programming easier without sacrificing the conceptual simplicity of Oberon. After three years of using Oberon and its experimental offspring Object Oberon we merged our experiences into a single refined version of Oberon. The new features of Oberon-2 are type-bound procedures, read-only export of variables and record fields, open arrays as pointer base types, and a with statement with variants. The for statement is reintroduced after having been eliminated in the step from Modula-2 to Oberon." ftp://ftp.inf.ethz.ch/pub/software/Oberon/OberonV4/Docu/Oberon2.Differences.ps.gz What a unique approach - exclude as many language features as you can - see what its like and then include the features that you really missed. > Now, getting to the referenced OBERON 2 paper. Thanks for the memory refresh! > > It was Oberon 2 which Herr Doctor Wirth presented at the UNC seminar I > mentioned. Having now looked at this paper I remember more of why I > had the reaction I did at the time. He even used the same examples in > the talk IIIRC. > > First of all, that paper pretty much takes it upon itself to define > object oriented programming, quoting: > > "Object-oriented programming is based on three concepts: data > abstraction, type extension and dynamic binding of a message to the > procedure that implements it. All these concepts are supported by > Oberon-2. We first discuss type extension since this is perhaps the > most important of the three notions, and then turn to type-bound > procedures, which allow data abstraction and dynamic binding." > > Now whether or not you think that Alan Kay 'owns' the definition of > OOP (more on that later). I don't think I've seen OOP expressed > exactly like this anywhere else. I guess it's kind of a Humpty Dumpty > in Wonderland technique, which is similar to some of the arguments in > Wirth's paper which prompted this thread. Why would you expect to see OOP expressed in terms of Oberon-2 features anywhere else :-) > > Type extension in Oberon 2 is really nothing more than Hoare's "Record > Classes" which predated Oberon. let alone Oberon 2 by over 20 years. > This technique for modeling abstract data types, was the key > difference between Simula and Simula 67, and was also the main element > of C++, which Stroustrup originally viewed as an implementation of > Simula 67 based on C rather than Algol. > > Abstract data types are still firmly rooted in the traditional > computational model which separates programs from the data on which > the programs operate. Programs were viewed as boxes with an input > funnel and an ouput chute. You poured in some data, the program > chewed on it, and data spewed out. Some here might be old enough to > remember the old HIPO diagrams (Hierarchy plus Input Process Output). > Which was the new-age (c. 1970) improvement on flowcharts. > > Kay's conception of OOP was that each object should be like a small > computer which combined data and program (methods) as an > implementation, and that the computation model should not require > details of the implementation to be known across the interface between > objects. This is a strong form of encapsulation. http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html > > In contrast, the encapsulation afforded by abstract data type > languages such as Oberon 2, C++, Eiffel, and to some extent, Java. Is > a kind of pseudo-encapsulation in which the compiler must examine > source code on both sides of an interface. Details of the > implementation are then 'hidden' by making access to them illegal. In > Oberon or C++ encapsulation errors result in compiler, or perhaps > linkage editor, errors, assuming that the programmer hasn't violated > encapsulation with low-level programming tricks. In a language with > Kay-encapsulation, implementation details just aren't visible from > another object. "pseudo encapsulation" is misleading at best - when an Oberon-2 program is being compiled, compilation of the import lists causes the /symbol files/ of imported modules to be read for exported identifiers, the public interfaces of the imported modules. There's no examination of source files. The implementation details (whatever that means) of imported modules were never made public when those modules were compiled. What's an "encapsulation error"? (imo when we talk about compilation or linkage errors we should acknowledge the other alternative is run time errors.) In a language with module encapsulation, implementation details just aren't visible from another module. > > Now comparing Oberon 2, as described in this paper, with C++, they > seem very similar, Abstract Data Types, which can be related via type > inheritance, and virtual functions, which have a prototypical > implementation using vtables. Note the description of how dynamic > binding to type-bound functions: > > "A message v.P is implemented as v^.tag^.ProcTab[Index-of-P]. " > > This is exactly the same as Stroustrup's implementation of virtual > function calls in C++. It's also an example of the kind of > implementation level information which is needed at compile and link > time, since Index-of-P depends on implementation details of the target > object. It's possible to get a little more flexibility by using more > dynamic techniques, but the implementors of these languages typically > see binding method selectors to an integer in the range 0 to the > number of methods -1 as a nearly irresistable premature optimization. > It's also one of the reasons that systems written in these kind of > languages have long build times, since there is a high degree of > dependency between source files. > > Now the new feature of Oberon 2, which prompted MY questioning of > Wirth during the seminar is it Message Records, which make Oberon > slouch a bit towards Smalltalk's computation model, but stumble at the > first step. > > Note that the rectangle's message handler is nothing more than a hand > coded typecase statement which discriminates on the message type. > Oberon 2 didn't really introduce late bound messages to the language, > it simply extended with (the typecase statement) to allow for type > extension. > > The actual message handling is just a stylized use of this feature. > Unlike Ruby or Smalltalk, message handling isn't a uniform mechanism > at the core of the language, it's just a design pattern. > > Languages like Ruby and Smalltalk typically do a much better job of > dispatching such dynamic messages than this kind of implementation > could ever do. Look at the analysis of the performance of messages: > > "- Messages are interpreted by the handler at run time and in > sequential order. This is much slower than the dynamic binding > mechanism of type-bound procedures, which requires only a table lookup > with a constant offset. Message records are much like messages in > Smalltalk [7], which are also interpreted at run time." > > The unstated assumption here is that messages in Oberon 2 is slow > that Smalltalk/Ruby dynamic message sending must be as slow. The > ad-hoc nature of messages precludes the kind of global optimizations > using caches and other techniques typically used by a Smalltalk > implementation. Ruby also does a certain amount of caching to avoid > running the class chain on every call. The Oberon approach can't avoid > running those custom written handler procedures. I don't know that anyone tried to optimize Oberon-2 message handlers, although the authors opinion is clear enough: "In general, type-bound procedures are clearer and type-safe, while message records are more flexible. One should use type-bound procedures whenever possible. Message records should only be used where special flexibility is needed, e.g., for broadcasting a message or for cases where it is important to add new messages to a type later without changing the module that declares the type." > > This difference between having a powerful, high-level runtime which > can optimize system-wide facilities like message dispatch and garbage > collection is one crucial aspect which distinguishes the > Smalltalk/Ruby and C++/Oberon clans. "a powerful, high-level runtime" - Oh you mean JVM :-) I guess you don't know that one of the big differences between Modula-2 and Oberon was that Oberon had GC: "We assume that retrieval of storage is performed automatically by a so-called storage reclamation mechanism, also called garbage collector." Programming in Oberon 1982 p41 http://www.oberon.ethz.ch/WirthPubl/ProgInOberon.pdf > > And that brings things back to Kay's view of OOP. The key concept in > KayOOP is strong encapsulation which is nearly diametrically opposed > to strong type checking. Message oriented computation, and GC are the > keys to providing that encapsulation. GC might not be so obvious, but > it would be hard to encapsulate interfaces between objects if the > objects needed to look out for each other's survival. In Kay's OOP, > classes and inheritance are secondary, and are there to provide for > factoring the sharing of implementation between objects with similar > implementation, not for modeling types so that procedures can run over > the data. > > Whether or not Alan Kay has the right to claim the definition of OOP, > the fact that it got hijacked by Peter Wegner in a paper which > misunderstood the differences in the meanings of classes and > inheritance in the two major groups of languages whihc use those terms > quite differently, is the foundation of the tower of babel which has > confounded conversations about Object Orientation for so many years. > > > -- > Rick DeNatale > > My blog on Ruby > http://talklikeaduck.denhaven2.com/