I think that it is mostly lack of experience in this space that is doing the talking here amongst Squeak folks.
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.
A module primarily defines variables in a local scope. Theoretically, it could have instance variables, could have methods, and could even allow instantiation. These abilities are not only secondary, but might not be necessary at all.
Looking at this, there isn't much of an intersection in the common uses. Why don't we just say that a class *has* a module (to hold class variables), and leave it at that?
Of course, I haven't implemented a Smalltalk modules system and developed it over 10 years, so I may be being naive here. I just worry about equating ideas just because their implementations share some features. Conceptually the two things are different, and thus implementing them as the same thing is bothersome. This is the core of the language, so let's keep it as clean as we can!
-Lex
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Lex Spoon Sent: Tuesday, February 26, 2002 12:33 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Modules and class... [ a off-topic question ?]
I think that it is mostly lack of experience in this space that is
doing
the talking here amongst Squeak folks.
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.
A module primarily defines variables in a local scope. Theoretically, it could have instance variables, could have methods, and could even allow instantiation. These abilities are not only secondary, but
might
not be necessary at all.
You've described a namespace, not a module.
-- Dave S. [www.smallscript.org]
Looking at this, there isn't much of an intersection in the common
uses.
Why don't we just say that a class *has* a module (to hold class variables), and leave it at that?
Of course, I haven't implemented a Smalltalk modules system and developed it over 10 years, so I may be being naive here. I just
worry
about equating ideas just because their implementations share some features. Conceptually the two things are different, and thus implementing them as the same thing is bothersome. This is the core
of
the language, so let's keep it as clean as we can!
-Lex
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.
Isn't this basically what Lex gives? How does this definition relate to the definition of "constructor" you are using? I think the discussion "modules and classes" will benefit from a common understanding of this basic term. Would it be possible that you elaborate a bit on this please?
Cheers Hannes Hirzel
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Hannes Hirzel Sent: Tuesday, February 26, 2002 11:28 PM To: squeak-dev@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.
Do you believe that to be a complete and accurate description of what Smalltalk-80 classes were at that time?
Do you believe that to be a complete and accurate description of what Smalltalk-98 classes were at the time of the ANSI standard?
If the answer to either of these questions is yes, then you should re-examine the implementations of classes within a Squeak image.
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.
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.
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? I think the discussion "modules and classes" will benefit from
a
common understanding of this basic term. Would it be possible that you elaborate a bit on this please?
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 from languages like C/C++/Pascal and other Algol derived languages. I.e., Look inside a shared-library file on Linux, or a DLL on Windows, or a CodeFragment on the MacOS.
-- Dave S. [www.smallscript.org]
Cheers Hannes Hirzel
Hi David and others
On Wed, 27 Feb 2002, David Simmons wrote:
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Hannes Hirzel Sent: Tuesday, February 26, 2002 11:28 PM To: squeak-dev@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 MetaclassHow 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
squeak-dev@lists.squeakfoundation.org
-
David Simmons -
Hannes Hirzel -
Lex Spoon