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

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Tue Feb 26 10:20:52 UTC 2002


"David Simmons" <David.Simmons at smallscript.com> wrote:
[SNIP]
> 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

It may very well be. On the other hand we do have some experienced guys
too! :-)
Like Les for example. So I don't think that is the only reason for our
reactions to your view.

Nevertheless I find your view very interesting and I am arguing because
I want to understand it better. And I do, as many others have testified,
very much value your input here - be sure of that.

> 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...

Ok, so your argument being that if a "module" can be defined using the
same freedom as we define classes AND we also make sure our architecture
for modules handles all that freedom then there will be much less limits
to what future module "types" can be/do.

Ok, I see what you mean. But... is it practical to give modules that
much freedom? And just being a dumb average Smalltalker here: How do you
compose your modules in Smallscript? How does a class "contain" other
classes? Just curious - I could of course download and dissect but I
have no time right now.

> > 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.

Well. Trying to define "function" is kindof tricky. I always think of
"functions" as having no state.
On the other hand you could just view any state it does have access to
as "parameters" and then, voila (hmmm, how do I get accents in Squeak on
Linux? Strange. I just get ´) it's a function!

But given that a class method does have access to the state in the class
object it is IMHO not a function. It's a class method. It can be
inherited on the class side for example. Functions don't normally
participate in inheritance, do they?

And given all this, in Smallscript (I am guessing here), since a module
is a class (and vice versa I guess) - a function in a module becomes
just a class method (or vice versa). And you can of course have
inheritance between modules since they are nothing else than classes.

Now... what mechanisms have you added to the "class" concept to make it
work as a "module concept" too?


> 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

The Module system in 3.3alpha actually removed Pools. In the light of
the Modules system they got redundant.

> 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.

Could you state your prediction? Is it that the current system will not
be able to handle more diversified "module" concepts?

But honestly, do we really need so many different kind of modules?

We have two different beasts today - Module and DeltaModule (the names
of the classes in question). They together capture quite a lot of
interesting functionality IMHO. And If we will need one or two more -
fine, we should be able to squeeze that in without too much trouble.

In short, in my opinion, which may be feebleminded since I am not even
close to David Simmons in grasping all the meta-level questions here
(and that was not meant as irony), I want a modules system which is
understandable by everyone and still powerful ENOUGH. Emphasis on
enough.

The idea to give "module" the same freedom that "class" has feels weird
to me. It would ALSO mean - and this is biggie - if we want to change
the modules system we would ALSO change the class system and vice versa.
I personally do not want them to be that tightly coupled.


[SNIP]
> > 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.

No, you are doing just fine I think. But you need to be prepared for
some fire when you are so bold to say we are all doing it totally wrong.
That hurts! :-) ;-)

regards, Göran



More information about the Squeak-dev mailing list