Modules and class... [ a off-topic question ?]Hannes Hirzel hirzel at spw.unizh.chFri Mar 1 01:21:24 UTC 2002
Hi David and others On Wed, 27 Feb 2002, David Simmons wrote: > > -----Original Message----- > > From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev- > > admin at lists.squeakfoundation.org] On Behalf Of Hannes Hirzel > > Sent: Tuesday, February 26, 2002 11:28 PM > > To: squeak-dev at lists.squeakfoundation.org > > Subject: RE: Modules and class... [ a off-topic question ?] > > > > > > Hi David, > > > > On Tue, 26 Feb 2002, David Simmons wrote: > > > > > Lex Spoon wrote: > > [snip] > > > > > > I think my intuitive decomposition of classes and modules may be > > > similar > > > > to others', so let me toss it out. > > > > > > > > A class primarily declares a number of instance variables, and > holds a > > > > number of methods, and can be instantiated. It can also define > > > > variables in a local scope, but that's secondary and not even > > > necessary > > > > if we have modules. > > > > > > You've described a constructor, not a class. > > > > > > > > > Are you sure? > > > > The classical definition: > > > > Goldberg / Robson - Smalltalk-80, 1989 ("Purple book") p.8 > > > > "A class _describes_ the implementation of a set of objects that all > > represent the same kind of system component. The individual objects > > described by a class are called its instances. A class describes the > form > > of its instances' private memories [i.e. instance variables, HH] and > it > > describes how they carry out their operations. > > > > Ok. That's a definition. I would say that's _the_ definition that captures the main point. Later in that book and in the implementation that is elaborated. > Do you believe that to be a complete and accurate description of what > Smalltalk-80 classes were at that time? No completeness and accuracy wasn't implied. I wanted go get accross what I consider to be the main point first. > Do you believe that to be a complete and accurate description of what > Smalltalk-98 classes were at the time of the ANSI standard? I just know that Dolphin and you are saying you are using Smalltalk-98. I'm not familiar with this flavor of Smalltalk. What are the specific 1998 additions? Their and your web-site are not especially talkative on this issue. Is this just a marketing term not to terrify people mentioning the year 80 and to mark that Smalltalk is still up to date? > If the answer to either of these questions is yes, then you should > re-examine the implementations of classes within a Squeak image. Good idea to base the disscussion more on what is actually there! The hierarchy in Squeak 3.3a-4769 is the following ProtoObject Object #() Behavior #('superclass' 'methodDict' 'format') ClassDescription #('instanceVariables' 'organization') Class #('subclasses' 'name' 'classPool' 'sharedPools' 'module' 'category') [ ... all the Metaclasses ... ] The class comments are for this time surprisingly revealing: -------- Behavior -------- My instances describe the behavior of other objects. I provide the minimum state necessary for compiling methods, and creating and running instances. Most objects are created as instances of the more fully supported subclass, Class, but I am a good starting point for providing instance-specific behavior (as in Metaclass). (I put this as well a new Swiki page http://minnow.cc.gatech.edu/squeak/2311 Anybody who has an additional note / comment / clarification is invited to post that there. I think it would be handy for the discussion to have some notes there.) ---------------- ClassDescription ---------------- http://minnow.cc.gatech.edu/squeak/2312 I add a number of facilities to basic Behaviors: - Named instance variables - Category organization for methods - The notion of a name of this class (implemented as subclass responsibility) - The maintenance of a ChangeSet, and logging changes on a file - Most of the mechanism for fileOut. I am an abstract class, in particular, my facilities are intended for inheritance by two subclasses, Class and Metaclass. The slots 'organization' and 'methodDict' should ONLY be accessed by message in order for things to work during ImageSegment>>discoverActiveClasses (q.v.). ----- Class ----- http://minnow.cc.gatech.edu/squeak/670 The class comment: I add a number of facilities to those in ClassDescription: - A set of all my subclasses (defined in ClassDescription, but only used here and below) - A name by which I can be found in a SystemDictionary - A classPool for class variables shared between this class and its metaclass - A list of sharedPools which probably should be supplanted by some better mechanism. My instances describe the representation and behavior of objects. I add more comprehensive programming support facilities to the basic attributes of Behavior and the descriptive facilities of ClassDescription. The slot 'subclasses' is a redundant structure. It is never used during execution, but is used by the development system to simplify or speed certain operations. ...... Additionaly the Swiki page http://minnow.cc.gatech.edu/squeak/670 has the following: A class defines the structure and behavior of it's instances. It holds a collection of the names of instance variables instances have. printIt - Class instanceVariablesString. A class holds a MethodDictionary, mapping messages to Edit Methods. These methods are precisely what is updated when you accept code in the browser. This dictionary is also where the Virtual Machine looks for the code to run for a message. InspectIt - Point methodDict Classes take care of lots of details - having a name that's global in the system (that's why writing "Point" above worked), keeping track of variables known to all the classes' instances. Many of the most important things classes know, they inherit from their superclass Behavior. It is Behavior that holds the method dictionary, and keeps track of the classes' superclass (see Inheritance). Playing with Behavior is one of the ways that Squeak lets us do radical things like playing with other representations of objects (for example, Objects without classes - aka, prototype systems). After you're comfortable with classes, you should investigate Metaclasses. In a way, they're sort of "the Dark Side of the class". OTOH, they help classes be objects themselves. --------------------------------------------------------------------------- > The description you provided is the description of a constructor. It is > not an adequate description of what a Smalltalk class is, as it has been > manifested in Smalltalk-80 and later implementations. > > > > > Isn't this basically what Lex gives? > > Yes, it is basically the definition Lex gives. It is just that both are > incomplete/abridged. They both describe a constructor, and are an > insufficient description for a Smalltalk class definition. > > If you think I am wrong, just take a look at all the arguments to a > class definition method in your Squeak image. Tell me how each one > relates to the definition provided. What does a Smalltalk class > declaration define and describe exactly? I am asking you to think > outside the stiflingly old/early and narrow box described in your quoted > definition and Lex's definition. See class comments above. I as well re-opened Rechenberg/Pomberger, Informatik-Handbuch, Hanser 1997; I had it just handy here ... somebody other might bring a citation from an English book. (I consider it to be the best German one-volume encyclopedias on computer science) p. 421 Klassen haben in objektorientierten Sprachen verschiedene Aufgaben - Sie definieren Datentypen, die in Deklarationen verwendet werden können - Sie bilden Mengen, deren Elemente die Objekte sind - Sie sind mit Modulen vergleichbare Strukturierungseinheiten - Sie dienen als Mechanismen zur Erzeugung von Objekten ("Objektfabriken") ...in English... In object-oriented languages classes have different tasks - they define data types - they define sets whose elements are the objects - they define structural units comparable to modules - they serve as mechanisms to construct objects ("Object factory, cookie cutter" - HH) First it would be nice if some of the teachers of software engineering out there could give a short summary on data types (there is an elaborate mathematically well founded theory in computer science behind it although it is generally said that computer languages implement that poorly. (Stephane Ducasse, Richard O'Keefe, Andrew P. Black, others ??) Second that definition actually includes the remark that supports your point somehow but we would have to make sure what definition of module we are actually using. For example the language where I learned the module concept was Modula-2 and there I didn't notice a module beeing something extraordiary. At least I did not think of a class at that time. > To look at meta-object protocol (MOP-services) OO software design, OO > languages and concepts, and how they have diversified and evolved to > their rich forms today, including in various Smalltalks. To look at the > union of those ideas in understanding what such a "class specification" > is. A friend of mine once recommended me to read the 'Art of the Meta Object Protocol' but I never did. If somebody could do a short Swiki summary on the points which are relevant for this discussion - that would be great. > Note, in QKS Smalltalk and in SmallScript the behavior hierarchy is: > > Object > Behavior > Constructor > Class > Metaclass > > > How does this definition relate to the definition of "constructor" you > are > > using? [snip] Thank you for this info. Could you give some indication on the similarities and differences of the Squeak hierarchy compared to Smallscript? For me it is unfamiliar to speak of constructor in the context of Smalltalk. I actually associate this with the notion of a method which constructs objects (Java/C++ influenced). > Lex described, in his most recent post, that: > > "A namespace is one of the most important parts of a module. Another > important part is dependency information, which normally wouldn't be > included in an individual class (you could, but it would seem like quite > a burden!). What aspect of modules have I left out, that you consider > important?" > > Like the constructor, vs class definition, Lex's definition of a module > is, at best, incomplete/abridged. > Take a look at the classic definitions and implementations of a module I'll check them out beginning of next week. For that I'll have to go to the library (I archived most of my books on this topic - I perceive this field still as beeing a chaos - other engineering disciplines could never be so messy). One interesting book I have here at the moment is: Clemens Szyperski Component software - beyond object-oriented programming. Addison-Wesley 1999 (Szyperski did his PhD under supervision of Niklaus Wirth and Hanspeter Mössenböck) He writes on p. 32 ...It should be clear that components are rather close to modules, as introduced by modular languages in the early 1980s. The most popular modular languages are Modula-2 and Ada. In Ada, modules are called packages, but the concepts are almost identical. An important hallmark of truly modular approaches is the support of separate compilation, including the ability to typecheck across module boundaries properly. With the introduction of the language Eiffel, it was claimed that a class is a better module (Meyer, 1988). This seemed to be justified based on the early ideas that modules would each implement one abstract data type (ADT). After all, a class can be seen as implementing an ADT, with the additional properties of inheritance and polymorphism. However, modules can be used, and always have been used, to package multiple entities, such as ADTs, or indeed classes, into one unit. Also, modules _do not_ have a concept of instantiation, whereas classes do. (emphasis mine) ... Then it goes on on Oberon and Modula 3 The problem seems to be that different module definitions (synchronically and diacronically) are flying around. So for the discussion I think it is good to base it on actual implementations and keep and edit notes on the Swiki. Answering this mail might involve quite a bit of your time - don't feel pressed to do it - you may as well chop it into parts; thank you for taking the time to contribute in any case. To sum up - I'm not convinced at the moment that it would be helpful to have Class subclass: #Module instead of Object subclass: #Module (as it is now in Henrik Gedenryd's current implementation) If it turned out later that would be beneficial, we probably can refactor this. I think a learning curve for the community is unavoidable and even necessary. Of course it can be shortened by various means, notably by your contribution. The danger of over-engineering things is always there and it's that what I fear. And: not to forget - as a student of an institution where Niklaus Wirth taught - getting rid of things is a good thing as well. I think this was a goal as well in the different iterations Smalltalk went through and we should keep this. Regards Hannes Hirzel
More information about the Squeak-dev mailing list |