"David Simmons" David.Simmons@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
squeak-dev@lists.squeakfoundation.org