Modules and class... [ a off-topic question ?]

David Simmons David.Simmons at smallscript.com
Tue Feb 26 03:10:20 UTC 2002


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Chris Becker
> Sent: Monday, February 25, 2002 9:23 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Modules and class... [ a off-topic question ?]
> 
> I completely agree with Göran here, as well as with Les.
> 
> If "a module should be a class", as David Simmons suggests, why not
just
> create a class called Module that inherits from Class? That's what you
> would
> do in a pure OO environment like Squeak in order to achieve that
desired
> result.

No. In a pure OO environment which SmallScript is, you would create a
new subclass of <Object>. The module's unique behavior is provided by
the "class" object itself.

I think that it is mostly lack of experience in this space that is doing
the talking here amongst Squeak folks. Consider what happens when you
need to define a new type of module. How will you package and deploy it
when nothing will understand it in base systems. It is very likely to
result in some kind of non-OO kludge mechanism...

> 
> But clearly, from David's examples, Smallscript is *not* a pure OO
> environment. Smallscript looks very cannibalized. 

> Functions vs. methods vs.

There is no versus. It sounds like you've not really understand what
classes are and how the MOP and behavior facilities support objects and
messaging. And, as a result, you do not understand the mechanisms by
which functions can be unified with an OO architecture. A function *is*
a class-method.

> messages, {braces} and [brackets],

{...} are a message form
[...] are a message form
(...) is a message form

Just like binary selectors are a message form.
Just like keyword selectors are a message form.

Which is why it is pure OO. It is through the unification of
classes/modules/namespaces that pure OO is retained. Selector namespace
design for pure OO functionality depends on it. It is not SmallScript
that is moving towards a break with OO in its design patterns...

> multiple meanings for (.), 

That is a necessity for human conventions in popular/mainstream
programming languages. Some pathing operator is required no matter what
you do. There are not too many options available in the symbol space.
Unfortunately for Smalltalk, the "." was defined as an expression
terminal rather than the ";" that is used in many other
"popular/mainstream" languages. Which says nothing about the fact that
cascade capability is very powerful and useful.

> interfaces
> that are classes, modules that are classes, classes that are
namespaces ...

However, that might be because you are not thinking deeply in OO terms
here. 

Interfaces are collections of behavior/methods. Therefore, they are a
type of behavior. However, they are also factories which requires that
they be a class.

Classes have shared/pool variables in classic Smalltalk. Therefore,
classes are already namespaces. Why retain SystemDictionary, or
non-class Pools, or introduce yet another namespace facility to confuse
everyone.

> I don't see how all this is going to help *Squeak*.
> 
> Most of the people who actively participate on this mailing list are
very
> passionate about keeping Squeak "pure".

"Pure" what?

Nothing I was suggesting had to do with the syntax extensions I
implemented in SmallScript to enable the language to step outside
Smalltalk's current box.

> They don't want to turn it into a
> hobgoblin of syntactic variation and confusing concepts. They merely
want
> to
> incrementally improve on a very simple and beautiful, yet powerful,
design.
> (And hats off to Dan Ingalls who has truly "loved his baby" all these
> years,
> nurturing it like a father does his child ... sorry ... getting
emotional
> now ... sniff-sniff.)
> 
> It's so easy to take a machete to something, hacking and slashing
parts
> off
> and sewing them back together to create a Frankenstein monster. It's
much
> more difficult to thoughtfully teach an evolving young mind (Squeak,
> formerly Smalltalk-80) new concepts without having it grow up confused
> with an identity crisis.

I agree completely. That is why it pains me to see some of the ideas
that have been implemented for namespaces in various Smalltalks. It is
also, what pains me as I see the work being done on modules, as I
project/foresee where it will put Squeak evolution a bit further down
the road.

> 
> Confused children make a confused world. The world is confused enough
as
> it is. Let's not confuse Squeak.

I am not trying to confuse or change Squeak -- to be honest it is
probably not even in my best interest to assist Squeak's evolution. It
is already changing, evolving, and maturing. I'm just trying to provide
some advice for the "child" (as you've characterized it) as it grows.
And, apparently, I'm doing a poor job of it.

-- Dave S. [www.smallscript.org]

> 
> Chris Becker
> 
> 
> -----Original Message-----
> From:	squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of
> goran.hultgren at bluefish.se
> Sent:	Monday, February 25, 2002 4:40 AM
> To:	squeak-dev at lists.squeakfoundation.org
> Subject:	Re: Modules and class... [ a off-topic question ?]
> 
> I read your thread and even though you both are much, MUCH more
> experienced in these areas I need to speak up. :-)
> 
> David certainly might have a point in that you CAN (perhaps with some
> mindbending IMHO) unify classes and modules - obviously he has done
it.
> :-) But just because you CAN do it... ;-)
> 
> To me it feels rather "contrived" (is that the right word?). As Les
> points out there are numerous differences and it doesn't feel obvious
at
> all (to me).
> 
> The most naive view of a module is that it is a collection of classes
> more or less self contained - it is a grouping of classes. So...
> following my naive reasoning (which I think is a great way of testing
if
> these conceptual things feels natural) - if a module is a class, and a
> module is a collection of classes, then a class is a collection of
> classes. BEEP. That doesn't sound right to me.
> 
> Ok, perhaps I did that wrong. Perhaps a module is "a kind of" class,
and
> I can not draw the conclusion that all classes are modules.
> 
> I still think this smells like "over unification" or something. No
> offense intended. :-) :-)
> 
> regards, Göran
> 
> PS. The Module system in Squeak OTOH feels nice to me - "A module is
an
> instance of the class Module and it holds classes and submodules etc."
> :-) :-) DS
> 
> 





More information about the Squeak-dev mailing list