Dan Ingalls wrote:
Apparently some of the new updates after modules have had their classes strangely classified. I say this because if you do a 'find...' in the left pane of a browser, they do not seem to be findable, even though they appear at the bottom of the leftmost pane.
Ok, the updates got out so fast I didn't have the time to say this in public:
There are now multiple name spaces, one per module.
So an important thing to keep in mind is that in subsequent change sets and especially updates, system categories in class definitions *have to* agree with that of the existing class, or a second class will be added in the module specified by the category. (Harvesters, in particular, keep this in mind.)
Since system categories are simulated from module path names, classes will be placed in *exactly* the module specified in the category of a class definition--even if the module doesn't exist. This is for reasonable backward compatibility.
So, new classes will be placed there obviously. But, for an existing class in a certain module, a *new class* will be created from the new class (re-) definition if it specifies a different module. This is not a bug, it is because every module has its own name space.
One could circumvent this by ignoring the category for any class already present under #(Squeak), but I don't think this would be a good thing, all things considered.
Do you know how to fix this so they can be found?
attached.
and/or warn so it doesn't happen in the future?
Umm, there is a warning for reusing class names, but they are suppressed during fileIn... suggestions?
write an update with code that will repair existing cases?
attached.
Finally, a warning: There are now (and have been) coming out updates that refactor the image. This should always be done on a non-modified, standard image.
If there are classes in improper places (ie. badly placed modules), they are in danger during refactoring. There is code to prevent this, but there are no guarantess that this will always work (although I don't see why it should happen).
Henrik
On Thu, 31 Jan 2002, Henrik Gedenryd wrote:
There are now multiple name spaces, one per module.
So an important thing to keep in mind is that in subsequent change sets and especially updates, system categories in class definitions *have to* agree with that of the existing class, or a second class will be added in the module specified by the category. (Harvesters, in particular, keep this in mind.)
Since system categories are simulated from module path names, classes will be placed in *exactly* the module specified in the category of a class definition--even if the module doesn't exist. This is for reasonable backward compatibility.
So, new classes will be placed there obviously. But, for an existing class in a certain module, a *new class* will be created from the new class (re-) definition if it specifies a different module. This is not a bug, it is because every module has its own name space.
One could circumvent this by ignoring the category for any class already present under #(Squeak), but I don't think this would be a good thing, all things considered.
I copied this important information on a new swiki page with the title 'Name spaces':
http://minnow.cc.gatech.edu/squeak/2221
This page can be accessed from 'Modules: Design Principles' http://minnow.cc.gatech.edu/squeak/2044
which in turn is accessed from the 'Modules' page
http://minnow.cc.gatech.edu/squeak/2042
There is a fair amount of initial information by Henrik and a compilation of this list's discussion on [modules] last autumn.
May I ask anybody interested to watch out for important information as well and update the pages as necessary.
Hannes Hirzel
Hi All,
Is it too late to have a hearty discussion here on the squeak discussion group regarding namespaces and modules?
I.e., have the plans for squeak been cast in stone. I've briefly read some of the module and namespace discussions on the Wiki.
If not then I would like to try and participate in a discussion on this area with the goal being to strive for some level of compatibility with existing Smalltalk implementations of namespaces, modules, etc such as in the work I've done for SmallScript (AOS and .NET versions), and its ancestor SmalltalkAgents (QKS Smalltalk).
I would add that this is area where simplicity is truly elegance in the best sense of Smalltalk's philosophy. But it is equally an area where recognizing synergies and making the right steps for achieving simplicity can be a hard thing to get right.
-- Dave S. [SmallScript LLC]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Hannes Hirzel Sent: Thursday, January 31, 2002 10:18 PM To: Squeak list Cc: Dan Ingalls; Doug Way; scott Subject: Re: [modules] Important: class re/definitions in change sets
and
updates
On Thu, 31 Jan 2002, Henrik Gedenryd wrote:
There are now multiple name spaces, one per module.
So an important thing to keep in mind is that in subsequent change
sets
and
especially updates, system categories in class definitions *have to*
agree
with that of the existing class, or a second class will be added in
the
module specified by the category. (Harvesters, in particular, keep
this
in
mind.)
Since system categories are simulated from module path names,
classes
will
be placed in *exactly* the module specified in the category of a
class
definition--even if the module doesn't exist. This is for reasonable backward compatibility.
So, new classes will be placed there obviously. But, for an existing
class
in a certain module, a *new class* will be created from the new
class
(re-)
definition if it specifies a different module. This is not a bug, it
is
because every module has its own name space.
One could circumvent this by ignoring the category for any class
already
present under #(Squeak), but I don't think this would be a good
thing,
all
things considered.
I copied this important information on a new swiki page with the title 'Name spaces':
http://minnow.cc.gatech.edu/squeak/2221
This page can be accessed from 'Modules: Design Principles' http://minnow.cc.gatech.edu/squeak/2044
which in turn is accessed from the 'Modules' page
http://minnow.cc.gatech.edu/squeak/2042
There is a fair amount of initial information by Henrik and a
compilation
of this list's discussion on [modules] last autumn.
May I ask anybody interested to watch out for important information as well and update the pages as necessary.
Hannes Hirzel
On Fri, 1 Feb 2002, David Simmons wrote:
Hi All,
Is it too late to have a hearty discussion here on the squeak discussion group regarding namespaces and modules?
I.e., have the plans for squeak been cast in stone. I've briefly read some of the module and namespace discussions on the Wiki.
If not then I would like to try and participate in a discussion on this area with the goal being to strive for some level of compatibility with existing Smalltalk implementations of namespaces, modules, etc such as in the work I've done for SmallScript (AOS and .NET versions), and its ancestor SmalltalkAgents (QKS Smalltalk).
I would add that this is area where simplicity is truly elegance in the best sense of Smalltalk's philosophy. But it is equally an area where recognizing synergies and making the right steps for achieving simplicity can be a hard thing to get right.
-- Dave S. [SmallScript LLC]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
[snip]
On Thu, 31 Jan 2002, Henrik Gedenryd wrote:
There are now multiple name spaces, one per module.
I copied this important information on a new swiki page with the title 'Name spaces':
I suppose that this might be a temporarily issue. The basic challenge which is now faced is how to refactor the image enough so that some large chunks can be put into modules.
At the moment the VM construction subsystem and the 3D system are the first candidates for loading/unloading as a module.
Stephan Ducasse and Ned Konz are doing some refactoring regarding the FileList as this is a class which has too many hard wired references from other classes. In this directions many things are underway.
I was surprised as well to learn that one module corresponds to one name space. But at the moment I feel at ease with it because the challenge is to chop out some five to seven large chunks of the image as modules living around a core system and still have a running system. In a sense I don't mind that a module lives in it's own name space.
There is also a to do list by Dan Ingalls on http://minnow.cc.gatech.edu/squeak/2066 (Modules: What to do next)
Cheers Hannes Hirzel
----- Original Message ----- From: David Simmons David.Simmons@smallscript.com To: squeak-dev@lists.squeakfoundation.org Cc: 'Dan Ingalls' Dan@SqueakLand.org; 'Doug Way' dway@riskmetrics.com; 'scott' scott@SqueakLand.org Sent: Friday, February 01, 2002 2:42 AM Subject: Namespace and Module Discussion
Hi All,
Is it too late to have a hearty discussion here on the squeak discussion group regarding namespaces and modules? I.e., have the plans for squeak been cast in stone. I've briefly read some of the module and namespace discussions on the Wiki. If not then I would like to try and participate in a discussion on this area with the goal being to strive for some level of compatibility with existing Smalltalk implementations of namespaces, modules, etc...
I think that this would be a worthwhile discussion, since it would be rather nice for there to exist a fair degree of inter-operability among the various Smalltalk dialects. Currently, namespaces and modules are evolving separately in each dialect. In the long term, this could be a problem for the overall health of the Smalltalk community. In the short term, this gives us different approaches with varying strengths and weaknesses, and in that sense could prove to be a good thing as we see how well each works in practice.
I would add that this is area where simplicity is truly elegance in the best sense of Smalltalk's philosophy. But it is equally an area where recognizing synergies and making the right steps for achieving simplicity can be a hard thing to get right.
I whole-heartedly agree with you on this point. It remains to be seen how this experiment will turn out in Squeak, but it is underway nonetheless.
- les
[snip]
I think that this would be a worthwhile discussion, since it would be rather nice for there to exist a fair degree of inter-operability among the various Smalltalk dialects. [snip]
About that, where can I find format specification for a "standard" .st file. By standard I mean for being loadable by other smalltalks (Dolphin, and specially VW) ?
Regards, Alexandre
Bergel Alexandre wrote:
[snip]
I think that this would be a worthwhile discussion, since it would be rather nice for there to exist a fair degree of inter-operability among the various Smalltalk dialects. [snip]
About that, where can I find format specification for a "standard" .st file. By standard I mean for being loadable by other smalltalks (Dolphin, and specially VW) ?
Regards, Alexandre
http://wiki.cs.uiuc.edu/CampSmalltalk/All+Projects
There are several projects dealing with this.
Karl
About that, where can I find format specification for a "standard" .st file. By standard I mean for being loadable by other smalltalks (Dolphin, and specially VW) ?
http://wiki.cs.uiuc.edu/CampSmalltalk/All+Projects
There are several projects dealing with this.
Ok, thanks you
Alexandre
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Les Tyrrell Sent: Friday, February 01, 2002 4:09 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Namespace and Module Discussion
----- Original Message ----- From: David Simmons David.Simmons@smallscript.com To: squeak-dev@lists.squeakfoundation.org Cc: 'Dan Ingalls' Dan@SqueakLand.org; 'Doug Way'
'scott' scott@SqueakLand.org Sent: Friday, February 01, 2002 2:42 AM Subject: Namespace and Module Discussion
Hi All,
Is it too late to have a hearty discussion here on the squeak
discussion
group regarding namespaces and modules? I.e., have the plans for squeak been cast in stone. I've briefly
read
some of the module and namespace discussions on the Wiki. If not then I would like to try and participate in a discussion on
this
area with the goal being to strive for some level of compatibility
with
existing Smalltalk implementations of namespaces, modules, etc...
I think that this would be a worthwhile discussion, since it would be rather nice for there to exist a fair degree of inter-operability
among
the various Smalltalk dialects. Currently, namespaces and modules are evolving separately in each dialect. In the long term, this could be
a
problem for the overall health of the Smalltalk community. In the
short
term, this gives us different approaches with varying strengths and weaknesses, and in that sense could prove to be a good thing as we see
how
well each works in practice.
In that vein, let me sally forth with a few comments:
For a variety of reasons (presumably to be uncovered in subsequent posts) the following rules hold in SmallScript:
a) Classes [class/metaclass pair as a unit] are binding-scopes (namespaces); most frequently referred to as "scope(s)". The class pool holds the variables.
b) Types for FFI and the optional type system, are classes. This implies lots of things... Not the least of which is that you can write the FFI marshalling code as methods within the class.
c) Modules are classes. Which implies a lot of things... Not the least of which is that modules can have unique behavior, and offer runtime scoping as a separate aspect/notion available within single unified object's capabilities.
d) Interfaces are classes. Lots to say here, but that would be a tangential discussion.
e) All runtime-binding-scoped elements are "owned" by one (and only one) module.
f) Modules are units of packaging/deployment. A "module" partitions deployment/loading of resources (including classes and methods). A "module" represents a "unit of packaging/deployment" for structuring/organizing availability of resources (including classes and methods).
g) A "scope" is a "unit of priviledge" which partitions runtime binding of variables and behavior. a "scope" [sometimes referred to as a namespace, but best referred to as a binding-scope] represents a "unit of priviledge" for runtime access-permission to "something within that scope".
h) Modules are assembled (packaged) as COFF/ELF/CodeFragment files by default [this offers innumerable benefits]. Where a COFF/ELF file may contain 0 or more modules. A pure module with no resources or externally compiled C/C++/Asm code is a self describing blob (and so can be packaged in any form desired). Any resources or and methods exported as callback entry points, are exposed directly through standard OS platform COFF/ELF/CodeFragment facilities.
i) Scoped methods (via selector namespaces) enable partitioning (scoping) of code changes within a given class. Remembering that by rule (e), all methods are owned by one, and only one, module.
j) Symbols are scoped. Every symbol consists of a common selector name, and a scope (as defined in (a)).
Given the above rules a system can be automatically sliced and diced into discrete shared-libraries (modules). Where a shared library can be loaded or unloaded on demand and offers native operating system program access to resources and exported entry points, digital certificates, etc.
The shared-library mechanism is possible because all of the environment/image changes a module makes are known through the "module" ownership rule(e). And because the selector-namespace rules for scoped-methods ensure that changes made to a common class, by different modules, are distinctly identified by rule(j).
-- Dave S. [SmallScript LLC]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
I would add that this is area where simplicity is truly elegance in
the
best sense of Smalltalk's philosophy. But it is equally an area
where
recognizing synergies and making the right steps for achieving simplicity can be a hard thing to get right.
I whole-heartedly agree with you on this point. It remains to be seen
how
this experiment will turn out in Squeak, but it is underway
nonetheless.
- les
----- Original Message ----- From: David Simmons David.Simmons@smallscript.com To: squeak-dev@lists.squeakfoundation.org Sent: Saturday, February 02, 2002 4:23 PM Subject: RE: Namespace and Module Discussion
In that vein, let me sally forth with a few comments:
For a variety of reasons (presumably to be uncovered in subsequent posts) the following rules hold in SmallScript:
a) Classes [class/metaclass pair as a unit] are binding-scopes (namespaces); most frequently referred to as "scope(s)". The class pool holds the variables.
c) Modules are classes. Which implies a lot of things... Not the least of which is that modules can have unique behavior, and offer runtime scoping as a separate aspect/notion available within single unified object's capabilities.
This has been proposed before for Squeak, originally ( AFAIK ) by Peter Novak, who had ported this from VW 3.0 where it had been done by Augustin Mrazik. I've also heard of several other proposals along those lines. But I've never understood why this sort of choice would be desireable - to me, it seems that a module already has plenty of other things to do in taking care of business, without also trying to act like a class. Here you are mentioning that it has some advantages in being able to provide what appears to be instance-specific behavior to a particular module. I suppose that being able to add behavior on a per-module basis would provide the greatest possible flexibility, but really how much of that is actually required, and if this is really an overly restrictive attitude on my part, what option other than making the module be a class would be available? To me, modules are not classes. They are not system dictionaries, either- I think both choices are incorrect as a model for what a module should be. At first blush, I don't think that modules should be able to "instantiate", thus should neither act as object factories or as object structural templates, or act as method repositories for other objects, all of which are things that only classes do. However, it seems to me that if you believe that modules should have instance-specific behaviors, then this can be accomplished without also carrying over the burden of all the other things that classes do. So, in a sense perhaps what you are reccomending is that a module should have *some* Metaclass-like behavior, ie, being able to define its own behavior in a totally self-contained and self-referential manner? Certainly there is precedent in the image for at least one object that does that sort of thing already.
d) Interfaces are classes. Lots to say here, but that would be a tangential discussion.
Again, are we talking about things that are going to instantiate? It seems to me that interfaces would not instantiate, but perhaps that is again an overly-restrictive view on my part. I've never envisioned them as being anything more than a way to describe, independent of clients and providers of certain "services", what those services are. Thus I would not expect Interfaces to define method implementations. So, I don't see the benefit in having Interfaces also be classes.
e) All runtime-binding-scoped elements are "owned" by one (and only one) module.
f) Modules are units of packaging/deployment. A "module" partitions deployment/loading of resources (including classes and methods). A "module" represents a "unit of packaging/deployment" for structuring/organizing availability of resources (including classes and methods).
g) A "scope" is a "unit of priviledge" which partitions runtime binding of variables and behavior. a "scope" [sometimes referred to as a namespace, but best referred to as a binding-scope] represents a "unit of priviledge" for runtime access-permission to "something within that scope".
i) Scoped methods (via selector namespaces) enable partitioning (scoping) of code changes within a given class. Remembering that by rule (e), all methods are owned by one, and only one, module.
j) Symbols are scoped. Every symbol consists of a common selector name, and a scope (as defined in (a)).
I can see where this would make it very easy to avoid conflicting definitions as multiple modules attempt to define the same method in the same class at the same time- If my understanding of this is correct, then for each module defining a method for a class that it does not itself define ( that is, a class "extended" by these modules ), there would be separate methods entered into that class's method dictionary, each selected by a Symbol which would have the same textual representation ( perhaps even the same canonical Symbol as representation ), but which would in fact be a different Symbol for each selector ( ie, one that might otherwise be printed as #ModuleA::doSomething or #ModuleB::doSomething, both of which are incarnations of the canonical Symbol #doSomething ). This is ( or should be ) possible because Symbols are objects, and this is actually all that the VM knows about them- so any objects can be used as selectors, including slightly more complex ones that are aware of both the module in which they are being used and the canonical symbol that they represent in that module.
What is not clear to me, is how ModuleA would refer to methods defined in other modules. For example, collection methods like #do: or Boolean methods such as #ifTrue: . These might actually have selectors known as #Base::do: , so how would methods in ModuleA invoke methods through these other selectors, defined for instance in Base? Or is it possible to implement selector namespacing without modifying the VM in some fashion? What I don't see is how methods compiled using the Symbols from one namespace will readily invoke methods compiled using the Symbols of a different namespace. In Oasis I've been fairly successful at isolating things, but haven't put as much effort into recombining them.
[ slightly re-arranged ]
b) Types for FFI and the optional type system, are classes. This implies lots of things... Not the least of which is that you can write the FFI marshalling code as methods within the class.
h) Modules are assembled (packaged) as COFF/ELF/CodeFragment files by default [this offers innumerable benefits]. Where a COFF/ELF file may contain 0 or more modules. A pure module with no resources or externally compiled C/C++/Asm code is a self describing blob (and so can be packaged in any form desired). Any resources or and methods exported as callback entry points, are exposed directly through standard OS platform COFF/ELF/CodeFragment facilities.
Given the above rules a system can be automatically sliced and diced into discrete shared-libraries (modules). Where a shared library can be loaded or unloaded on demand and offers native operating system program access to resources and exported entry points, digital certificates, etc.
It appears that these items have much more to do with Smalltalk inter-operability with other languages, and that you are going significantly beyond merely having a modular Smalltalk, to one that is also inter-operable with "modules" written in other languages. My own aims were quite a bit lower than this- I just wanted to have control over the composition of my own image. I'd actually be quite happy if that were all that were achieved. However, if this additional capability is also within reach then certainly it is worth considering.
The shared-library mechanism is possible because all of the environment/image changes a module makes are known through the "module" ownership rule(e). And because the selector-namespace rules for scoped-methods ensure that changes made to a common class, by different modules, are distinctly identified by rule(j).
Hence cross-dialect Smalltalk inter-operability ( as a subset of cross-language inter-operability ) , if we get it right?
- les
squeak-dev@lists.squeakfoundation.org