Smalltalk › Squeak › Squeak - Dev

Name spaces in Spoon

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

38 messages Options

Ralph Johnson

Name spaces in Spoon

I'm just getting into Spoon (hmm, I'm just learning to use Spoon, I'm
getting stirred up with Spoon, ... there ought to be a good line here)
so I'm probably making some mistakes, but mailiing lists are good for
finding that out.

My guess is that Spoon doesn't implement the global variable
Smalltalk. I'm going to assume that people know that the global
variable Smalltalk is implemented as a dictionary (a SystemDictionary,
actually) and that global variables are implemented as Associations.

SystemDictionary needs to be nested. Each module should have its own
"global variable Smalltalk", i.e. its own SystemDictionary that holds
the names of all classes. The compiler looks up a name by looking in
a dictionary, but a SystemDictionary will look in its parent if it
doesn't have its own copy. This way, two modules can each have a class
with the same name and the two classes won't collide.

I recently read (probably in squeak-dev) a proposal to standardize
the way people use prefixes to ensure that class names don't collide.
It was something like Prefix::ClassName and the point was that only
one or two places in the image had to change to legalize that kind of
name. If "Prefix" was the module name, and if we ensured that module
names were unique, and if importing a module caused all the classes in
the module's local version of Smalltalk to be added to the root
version of Smalltalk with this prefix added, then very little would
have to change in the programming environment.

-Ralph Johnson

John Pierce-2

Re: Name spaces in Spoon

On 5/25/06, Ralph Johnson <[hidden email]> wrote:
> I'm just getting into Spoon (hmm, I'm just learning to use Spoon, I'm
> getting stirred up with Spoon, ... there ought to be a good line here)

"I'm just starting to dig in with Spoon"

- John
--
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all
progress depends on the unreasonable man. -- George Bernard Shaw

timrowledge

Re: Name spaces in Spoon

On 25-May-06, at 9:13 AM, John Pierce wrote:

> On 5/25/06, Ralph Johnson <[hidden email]> wrote:
>> I'm just getting into Spoon (hmm, I'm just learning to use Spoon, I'm
>> getting stirred up with Spoon, ... there ought to be a good line
>> here)
>
> "I'm just starting to dig in with Spoon"
getting a handle on Spoon

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LB: connect Line-voltage to BITNET

SmallSqueak

Re: Name spaces in Spoon

In reply to this post by Ralph Johnson

> I'm just getting into Spoon (hmm, I'm just learning to use Spoon, I'm
> getting stirred up with Spoon, ... there ought to be a good line here)

"I'm trying to consume spaghetty with Spoon"

;-)

Cheers,

SmallSqueak

Göran Krampe

Re: Name spaces in Spoon

In reply to this post by Ralph Johnson

Hi Ralph!

"Ralph Johnson" <[hidden email]> wrote:
> SystemDictionary needs to be nested. Each module should have its own

I don't agree. :) If you look at 3.3alpha with modules (by late Henrik
Gedenryd mainly, which was abandoned) it has an elaborate nested
architecture based on the same idea which Dan actually started with the
environment instvar etc.

IMHO one of the reasons that the 3.3 modules adventure ended with
abandonment was the complexity of imports/exports in a nested hierarchy.

I advocate having a "flat" model with simply named buckets of names, as
in my Namespace solution (see below).

> "global variable Smalltalk", i.e. its own SystemDictionary that holds
> the names of all classes. The compiler looks up a name by looking in
> a dictionary, but a SystemDictionary will look in its parent if it
> doesn't have its own copy. This way, two modules can each have a class
> with the same name and the two classes won't collide.

Yes, all nice in theory. I am however weary of the effects in practice.
It is quite a step away from the current very simple and immediate
system, just like the Modules-3.3 was, and look where that ended.

I simply think that baby steps are needed here. Revolution is fine, but
risky. An example of "evolution" proving itself is Monticello. By using
just a few simple tricks it manages to work perfectly inside the
existing Squeak environment. And that is IMHO the reason for its
success.

> I recently read (probably in squeak-dev) a proposal to standardize
> the way people use prefixes to ensure that class names don't collide.

That was my proposal which I have presented on numerous occasions. The
latest little writeup of it (with tongue in cheek) is here:

http://swiki.krampe.se/gohu/32

...and here is code (I have it updated for 3.9, but haven't published it
yet:

http://map.squeak.org/packagebyname/namespaces

The very short description is that it adds the ability to have class
names with the prefix separated using "::". The system will then
consider the prefix a Namespace and it will even create instances of the
Namespace class etc. But in the end all classes still hang in Smalltalk
and all old code works fine. The neat thing is that just like with
Monticello all old tools work just fine.

I restricted it to one level though, so there is no hierarchy.

> It was something like Prefix::ClassName and the point was that only
> one or two places in the image had to change to legalize that kind of
> name.

Yes, the patch to get a Squeak image to accept code using such global
names is very, very small. This means that old images without this
support can very easily be patched, IIRC it was 3 methods touched in
Scanner and Parser or something like that.

> If "Prefix" was the module name, and if we ensured that module
> names were unique, and if importing a module caused all the classes in
> the module's local version of Smalltalk to be added to the root
> version of Smalltalk with this prefix added, then very little would
> have to change in the programming environment.

As my code actually shows. Just try it. And yes, I should post my 3.9
version.

> -Ralph Johnson

regards, Göran

Ralph Johnson

Re: Name spaces in Spoon

On 5/26/06, [hidden email] <[hidden email]> wrote:

> Hi Ralph!
>
> "Ralph Johnson" <[hidden email]> wrote:
> > SystemDictionary needs to be nested. Each module should have its own
>
> IMHO one of the reasons that the 3.3 modules adventure ended with
> abandonment was the complexity of imports/exports in a nested hierarchy.
>
> I advocate having a "flat" model with simply named buckets of names, as
> in my Namespace solution (see below).

I like your model for Squeak, but it won't work for Spoon. Note that
my message was a response to the problem that in Spoon it is easy for
different modules to have classes with the same name. So, I wondered
how "Smalltalk at: className" would work in Spoon. Prefixing names
would help if it were mandatory, but not if it were optional, and so
it seemed to revolutionary to me. Like you, I think that evolution of
the class library is better than revolution.

IMy model has no import/export rules. To the user, it is nearly the
same as the current model. I did not deal with problems in
disambiguating class names because no existing code will have that
problem. However, new code will, because if you import two modules
that define a class with the same name and then try to use one of
them, there will need to be a way to distinquish which one you mean.
But no existing code can have that problem.

> > I recently read (probably in squeak-dev) a proposal to standardize
> > the way people use prefixes to ensure that class names don't collide.
>
> That was my proposal which I have presented on numerous occasions. The
> latest little writeup of it (with tongue in cheek) is here:
>
> http://swiki.krampe.se/gohu/32
>
> ...and here is code (I have it updated for 3.9, but haven't published it
> yet:
>
> http://map.squeak.org/packagebyname/namespaces
>

-Ralph Johnson

Alejandro F. Reimondo

Re: Name spaces in Spoon

In reply to this post by Göran Krampe

Hi,

> > It was something like Prefix::ClassName and the point was that only
> > one or two places in the image had to change to legalize that kind of
> > name.
> Yes, the patch to get a Squeak image to accept code using such global
> names is very, very small.

What do you think about sending the name
as message...
MyGlobalContext::ThisClass
becomes:
MyGlobalContext ThisClass
the global context (aNameSpace, anEnvironment
or SystemDictionary)
can respond to the message returning the real
object (or via dnu build a method to return it)
Using this "trick" we do not need new syntax
and the solution is solved as usual (sending messages).

bets,
Ale.

----- Original Message -----
From: <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, May 26, 2006 7:36 AM
Subject: Re: Name spaces in Spoon

> Hi Ralph!
>
> "Ralph Johnson" <[hidden email]> wrote:
> > SystemDictionary needs to be nested. Each module should have its own
>
> I don't agree. :) If you look at 3.3alpha with modules (by late Henrik
> Gedenryd mainly, which was abandoned) it has an elaborate nested
> architecture based on the same idea which Dan actually started with the
> environment instvar etc.
>
> IMHO one of the reasons that the 3.3 modules adventure ended with
> abandonment was the complexity of imports/exports in a nested hierarchy.
>
> I advocate having a "flat" model with simply named buckets of names, as
> in my Namespace solution (see below).
>
> > "global variable Smalltalk", i.e. its own SystemDictionary that holds
> > the names of all classes. The compiler looks up a name by looking in
> > a dictionary, but a SystemDictionary will look in its parent if it
> > doesn't have its own copy. This way, two modules can each have a class
> > with the same name and the two classes won't collide.
>
> Yes, all nice in theory. I am however weary of the effects in practice.
> It is quite a step away from the current very simple and immediate
> system, just like the Modules-3.3 was, and look where that ended.
>
> I simply think that baby steps are needed here. Revolution is fine, but
> risky. An example of "evolution" proving itself is Monticello. By using
> just a few simple tricks it manages to work perfectly inside the
> existing Squeak environment. And that is IMHO the reason for its
> success.
>
> > I recently read (probably in squeak-dev) a proposal to standardize
> > the way people use prefixes to ensure that class names don't collide.
>
> That was my proposal which I have presented on numerous occasions. The
> latest little writeup of it (with tongue in cheek) is here:
>
> http://swiki.krampe.se/gohu/32
>
> ...and here is code (I have it updated for 3.9, but haven't published it
> yet:
>
> http://map.squeak.org/packagebyname/namespaces
>
> The very short description is that it adds the ability to have class
> names with the prefix separated using "::". The system will then
> consider the prefix a Namespace and it will even create instances of the
> Namespace class etc. But in the end all classes still hang in Smalltalk
> and all old code works fine. The neat thing is that just like with
> Monticello all old tools work just fine.
>
> I restricted it to one level though, so there is no hierarchy.
>
> > It was something like Prefix::ClassName and the point was that only
> > one or two places in the image had to change to legalize that kind of
> > name.
>
> Yes, the patch to get a Squeak image to accept code using such global
> names is very, very small. This means that old images without this
> support can very easily be patched, IIRC it was 3 methods touched in
> Scanner and Parser or something like that.
>
> > If "Prefix" was the module name, and if we ensured that module
> > names were unique, and if importing a module caused all the classes in
> > the module's local version of Smalltalk to be added to the root
> > version of Smalltalk with this prefix added, then very little would
> > have to change in the programming environment.
>
> As my code actually shows. Just try it. And yes, I should post my 3.9
> version.
>
> > -Ralph Johnson
>
> regards, Göran
>

Michael Latta

RE: Name spaces in Spoon

Since class names are just used to resolve to an object (unlike in most
other languages where there is special semantics) this proposal is the most
elegant I have seen. Once again Smalltalk allows extension without new
syntax or semantics because of its deep OO roots. The only implied
semantics that may be of interest:

1) When a new class is created and inserted into Smalltalk should there be a
new selector that instead inserts it into the SystemDictionary provided as
an argument?

2) I can not think of another implied use of class names that needs to be
addressed.

My real question about all this is "What is the real issue here?" All you
get with any namespace system is shorter names that the user must spend more
time interpreting. If there are multiple implied namespaces (rather than
explicit as in this case) the user must guess what name the compiler is
using. When there are explicit namespaces as in either proposal below all
you get is longer names than with the current convention. Having used Java
namespaces for years I suggest that they are mostly not necessary in
Smalltalk. When binary classes are provided as in Java you must have a
system to prevent classes from using the same name up front. In Smalltalk
names are only used for compiler access. So if you have source they can
always be refactored, and if you do not have source you probably do not need
to reference the names except at the boundary of the module. When
referencing a class at the boundary of a module, a module level dictionary
of classes would suffice. I think the namespace issue is a non-issue, and
the real issue as Spoon/Montecello has addressed is one of modularization.

Michael

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
Alejandro F. Reimondo
Sent: Friday, May 26, 2006 8:28 AM
To: The general-purpose Squeak developers list
Subject: Re: Name spaces in Spoon

Hi,

> > It was something like Prefix::ClassName and the point was that only
> > one or two places in the image had to change to legalize that kind of
> > name.
> Yes, the patch to get a Squeak image to accept code using such global
> names is very, very small.

What do you think about sending the name
as message...
MyGlobalContext::ThisClass
becomes:
MyGlobalContext ThisClass
the global context (aNameSpace, anEnvironment
or SystemDictionary)
can respond to the message returning the real
object (or via dnu build a method to return it)
Using this "trick" we do not need new syntax
and the solution is solved as usual (sending messages).

bets,
Ale.

----- Original Message -----
From: <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, May 26, 2006 7:36 AM
Subject: Re: Name spaces in Spoon

Diego Fernández

Re: Name spaces in Spoon

Michael, I used to work in Java too, and I agree that imports and name
spaces are very uncomfortable :(

And what about Tweak Islands?
http://tweak.impara.de/TECHNOLOGY/Whitepapers/Islands/

I have never use them but for the description they looks like having a
"a module level dictionary", is that right?

(the only thing that I don't like from the examples are that all
objects responds to #island
for me this is not so good, because is mixing different meta levels...
well is the same as: self class :( - I have never used Self, but
Object Mirrors looks like a good idea for me)

On 5/26/06, Michael Latta <[hidden email]> wrote:

> Since class names are just used to resolve to an object (unlike in most
> other languages where there is special semantics) this proposal is the most
> elegant I have seen. Once again Smalltalk allows extension without new
> syntax or semantics because of its deep OO roots. The only implied
> semantics that may be of interest:
>
> 1) When a new class is created and inserted into Smalltalk should there be a
> new selector that instead inserts it into the SystemDictionary provided as
> an argument?
>
> 2) I can not think of another implied use of class names that needs to be
> addressed.
>
> My real question about all this is "What is the real issue here?" All you
> get with any namespace system is shorter names that the user must spend more
> time interpreting. If there are multiple implied namespaces (rather than
> explicit as in this case) the user must guess what name the compiler is
> using. When there are explicit namespaces as in either proposal below all
> you get is longer names than with the current convention. Having used Java
> namespaces for years I suggest that they are mostly not necessary in
> Smalltalk. When binary classes are provided as in Java you must have a
> system to prevent classes from using the same name up front. In Smalltalk
> names are only used for compiler access. So if you have source they can
> always be refactored, and if you do not have source you probably do not need
> to reference the names except at the boundary of the module. When
> referencing a class at the boundary of a module, a module level dictionary
> of classes would suffice. I think the namespace issue is a non-issue, and
> the real issue as Spoon/Montecello has addressed is one of modularization.
>
> Michael
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Alejandro F. Reimondo
> Sent: Friday, May 26, 2006 8:28 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Name spaces in Spoon
>
> Hi,
>
> > > It was something like Prefix::ClassName and the point was that only
> > > one or two places in the image had to change to legalize that kind of
> > > name.
> > Yes, the patch to get a Squeak image to accept code using such global
> > names is very, very small.
>
> What do you think about sending the name
> as message...
> MyGlobalContext::ThisClass
> becomes:
> MyGlobalContext ThisClass
> the global context (aNameSpace, anEnvironment
> or SystemDictionary)
> can respond to the message returning the real
> object (or via dnu build a method to return it)
> Using this "trick" we do not need new syntax
> and the solution is solved as usual (sending messages).
>
> bets,
> Ale.
>
>
>
>
> ----- Original Message -----
> From: <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Friday, May 26, 2006 7:36 AM
> Subject: Re: Name spaces in Spoon
>
>
> > Hi Ralph!
> >
> > "Ralph Johnson" <[hidden email]> wrote:
> > > SystemDictionary needs to be nested. Each module should have its own
> >
> > I don't agree. :) If you look at 3.3alpha with modules (by late Henrik
> > Gedenryd mainly, which was abandoned) it has an elaborate nested
> > architecture based on the same idea which Dan actually started with the
> > environment instvar etc.
> >
> > IMHO one of the reasons that the 3.3 modules adventure ended with
> > abandonment was the complexity of imports/exports in a nested hierarchy.
> >
> > I advocate having a "flat" model with simply named buckets of names, as
> > in my Namespace solution (see below).
> >
> > > "global variable Smalltalk", i.e. its own SystemDictionary that holds
> > > the names of all classes. The compiler looks up a name by looking in
> > > a dictionary, but a SystemDictionary will look in its parent if it
> > > doesn't have its own copy. This way, two modules can each have a class
> > > with the same name and the two classes won't collide.
> >
> > Yes, all nice in theory. I am however weary of the effects in practice.
> > It is quite a step away from the current very simple and immediate
> > system, just like the Modules-3.3 was, and look where that ended.
> >
> > I simply think that baby steps are needed here. Revolution is fine, but
> > risky. An example of "evolution" proving itself is Monticello. By using
> > just a few simple tricks it manages to work perfectly inside the
> > existing Squeak environment. And that is IMHO the reason for its
> > success.
> >
> > > I recently read (probably in squeak-dev) a proposal to standardize
> > > the way people use prefixes to ensure that class names don't collide.
> >
> > That was my proposal which I have presented on numerous occasions. The
> > latest little writeup of it (with tongue in cheek) is here:
> >
> > http://swiki.krampe.se/gohu/32
> >
> > ...and here is code (I have it updated for 3.9, but haven't published it
> > yet:
> >
> > http://map.squeak.org/packagebyname/namespaces
> >
> > The very short description is that it adds the ability to have class
> > names with the prefix separated using "::". The system will then
> > consider the prefix a Namespace and it will even create instances of the
> > Namespace class etc. But in the end all classes still hang in Smalltalk
> > and all old code works fine. The neat thing is that just like with
> > Monticello all old tools work just fine.
> >
> > I restricted it to one level though, so there is no hierarchy.
> >
> > > It was something like Prefix::ClassName and the point was that only
> > > one or two places in the image had to change to legalize that kind of
> > > name.
> >
> > Yes, the patch to get a Squeak image to accept code using such global
> > names is very, very small. This means that old images without this
> > support can very easily be patched, IIRC it was 3 methods touched in
> > Scanner and Parser or something like that.
> >
> > > If "Prefix" was the module name, and if we ensured that module
> > > names were unique, and if importing a module caused all the classes in
> > > the module's local version of Smalltalk to be added to the root
> > > version of Smalltalk with this prefix added, then very little would
> > > have to change in the programming environment.
> >
> > As my code actually shows. Just try it. And yes, I should post my 3.9
> > version.
> >
> > > -Ralph Johnson
> >
> > regards, Göran
> >
>
>
>
>

Göran Krampe

Re: Name spaces in Spoon

In reply to this post by Alejandro F. Reimondo

Hi!

"Alejandro F. Reimondo" <[hidden email]> wrote:

> Hi,
>
> > > It was something like Prefix::ClassName and the point was that only
> > > one or two places in the image had to change to legalize that kind of
> > > name.
> > Yes, the patch to get a Squeak image to accept code using such global
> > names is very, very small.
>
> What do you think about sending the name
> as message...
> MyGlobalContext::ThisClass
> becomes:
> MyGlobalContext ThisClass
> the global context (aNameSpace, anEnvironment
> or SystemDictionary)
> can respond to the message returning the real
> object (or via dnu build a method to return it)
> Using this "trick" we do not need new syntax
> and the solution is solved as usual (sending messages).
>
> bets,
> Ale.

Just wish to note that this approach was indeed tested IIRC in the
3.3modules code, and if my memory serves me right Dan proposed it - but
I am not sure. Personally I was hesitant at the time, and still is.

A few comments:

1. It would move the binding time to runtime instead of compile time (or
if you prefer to call it "code install"-time). I can probably imagine
both pros and cons with that. It is a big change.

2. In my personal opinion it is less readable than
MyGlobalContext::ThisClass. It blends into the rest of the code so that
the reference itself doesn't "stand out". It also deviates from the
"words beginning with capitals refer to classes (or globals)".

3. The :: solution actually does not "need new syntax". It just needs us
to allow $: in global names. Sure, you can call it a "syntax change" -
but it is very, very small.

regards, Göran

Ralph Johnson

Re: Name spaces in Spoon

In reply to this post by Göran Krampe

I've been continuing to think about the problem. I said earlier today
that Göran was missing the fact that Spoon allows two or more classes
to have the same name, and Craig Latta said that was one of its
features. But then I realized that perhaps Göran thought that was a
bug, not a feature, and that he wanted all classes in a module to have
the module name as a prefix. In that case, two classes would never
have the same name.

If all classes in a module had the module name as a prefix then we
couldn't say "Set", we'd have to say something like ANSI::Set (because
it is a class from the ANSI standard). The rename refactoring would
fix all the old code to use the new name, but converting old code
would still be a bit of a pain.

-Ralph Johnson

Michael Latta

RE: Name spaces in Spoon

In reply to this post by Göran Krampe

You can not treat :: as "just part of the name" as that conflicts with : as
a separator in keyword selectors, or would at least make the job of the
scanner much more difficult. I do see the value in processing the :: at
compile time rather than doing a simple message send to a dictionary which
would do class name resolution at run-time.

It is not a huge syntax change, but since it has unique semantics I would
advise treating it as a syntax change rather than just adding characters to
the name space. If you really want it to just be part of the name so that
all such names appear in the system dictionary then I would advise using a
character that is not already used in the language. You could also simply
say that all names should have a prefix and solve it by convention. That
would make a structured browser less reliable however, so some extra
metadata that separates the prefix from the proper name is warranted.

Maybe :: is not so bad, and should just be part of the name. Or we could
just allow objects to be embedded in source code and we do not need class
names, literals, etc.

Michael

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Friday, May 26, 2006 12:58 PM
To: The general-purpose Squeak developers list
Subject: Re: Name spaces in Spoon

Hi!

"Alejandro F. Reimondo" <[hidden email]> wrote:

Göran Krampe

Re: Name spaces in Spoon

In reply to this post by Ralph Johnson

Hi!

"Ralph Johnson" <[hidden email]> wrote:
> I've been continuing to think about the problem. I said earlier today
> that Göran was missing the fact that Spoon allows two or more classes
> to have the same name, and Craig Latta said that was one of its
> features. But then I realized that perhaps Göran thought that was a
> bug, not a feature, and that he wanted all classes in a module to have
> the module name as a prefix. In that case, two classes would never
> have the same name.

Well, I can't say that I am passing any criticism on Spoon - I know too
little about it - I am merely presenting my approach as a different way
of dealing with these issues.

But yes, in my approach a class name is "Blabla::Blupp" or just "Blupp".
Obviously those two names are not the same. Nor is "Blibli::Blupp".

Two classes could still end up with the same name if:

1. You don't use a Blabla:: prefix.
2. You end up using the same prefix (namespace) as someone else.

There are ways to solve these situations too - like remapping names on
import, or having a prefix registry somewhere to minimize #2.

> If all classes in a module had the module name as a prefix then we
> couldn't say "Set", we'd have to say something like ANSI::Set (because
> it is a class from the ANSI standard).

But if you play with my code you realize that the tools "render" the
class names short - if the short name is unique in your image - which it
most surely is. Net effect: Almost always short names.

Same goes for typing them.

> The rename refactoring would
> fix all the old code to use the new name, but converting old code
> would still be a bit of a pain.

No, not really - because you don't *have to* put classes under prefixes!
So old code works just fine.

> -Ralph Johnson

regards, Göran

Michael Latta

RE: Name spaces in Spoon

In reply to this post by Michael Latta

Come to think of it : is already allowed in symbols, so this may be a
non-issue. I would need to check the scanner code more directly.

What I strongly advise against is having short names be able to match long
names by virtue of being in a "context" that somehow "imports" or implicitly
qualifies names. Down that road lies much unneeded confusion and
complexity.

Michael

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael
Latta
Sent: Friday, May 26, 2006 2:25 PM
To: 'The general-purpose Squeak developers list'
Subject: RE: Name spaces in Spoon

You can not treat :: as "just part of the name" as that conflicts with : as
a separator in keyword selectors, or would at least make the job of the
scanner much more difficult. I do see the value in processing the :: at
compile time rather than doing a simple message send to a dictionary which
would do class name resolution at run-time.

It is not a huge syntax change, but since it has unique semantics I would
advise treating it as a syntax change rather than just adding characters to
the name space. If you really want it to just be part of the name so that
all such names appear in the system dictionary then I would advise using a
character that is not already used in the language. You could also simply
say that all names should have a prefix and solve it by convention. That
would make a structured browser less reliable however, so some extra
metadata that separates the prefix from the proper name is warranted.

Maybe :: is not so bad, and should just be part of the name. Or we could
just allow objects to be embedded in source code and we do not need class
names, literals, etc.

Michael

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Friday, May 26, 2006 12:58 PM
To: The general-purpose Squeak developers list
Subject: Re: Name spaces in Spoon

Hi!

"Alejandro F. Reimondo" <[hidden email]> wrote:

Alejandro F. Reimondo

Re: Name spaces in Spoon

In reply to this post by Göran Krampe

Hi!,

> A few comments:
thanks!

> 1. It would move the binding time to runtime instead of compile time (or
> if you prefer to call it "code install"-time). I can probably imagine
> both pros and cons with that. It is a big change.

The method that implements the message will be simply
a return of an association.
It is solved without activating a method context (like
primitive methods that do not fail); so the time spent in getting
the real object is too small and dynamically optimizable.

> 2. In my personal opinion it is less readable than
> MyGlobalContext::ThisClass. It blends into the rest of the code so that
> the reference itself doesn't "stand out". It also deviates from the
> "words beginning with capitals refer to classes (or globals)".

MyGlobalContext thisClass

can also be used and hacked by dnu mechanism.

> 3. The :: solution actually does not "need new syntax". It just needs us
> to allow $: in global names. Sure, you can call it a "syntax change" -
> but it is very, very small.

On the "pros" side we must consider that mesage sending
can be used to reroute class targets, do some profiling, ...
or pinging to remote objects (to move bechavior when
really needed).

cheers,
Ale.

----- Original Message -----
From: <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, May 26, 2006 4:57 PM
Subject: Re: Name spaces in Spoon

> Hi!
>
> "Alejandro F. Reimondo" <[hidden email]> wrote:
> > Hi,
> >
> > > > It was something like Prefix::ClassName and the point was that only
> > > > one or two places in the image had to change to legalize that kind
of

> > > > name.
> > > Yes, the patch to get a Squeak image to accept code using such global
> > > names is very, very small.
> >
> > What do you think about sending the name
> > as message...
> > MyGlobalContext::ThisClass
> > becomes:
> > MyGlobalContext ThisClass
> > the global context (aNameSpace, anEnvironment
> > or SystemDictionary)
> > can respond to the message returning the real
> > object (or via dnu build a method to return it)
> > Using this "trick" we do not need new syntax
> > and the solution is solved as usual (sending messages).
> >
> > bets,
> > Ale.
>
> Just wish to note that this approach was indeed tested IIRC in the
> 3.3modules code, and if my memory serves me right Dan proposed it - but
> I am not sure. Personally I was hesitant at the time, and still is.
>
> A few comments:
>
> 1. It would move the binding time to runtime instead of compile time (or
> if you prefer to call it "code install"-time). I can probably imagine
> both pros and cons with that. It is a big change.
>
> 2. In my personal opinion it is less readable than
> MyGlobalContext::ThisClass. It blends into the rest of the code so that
> the reference itself doesn't "stand out". It also deviates from the
> "words beginning with capitals refer to classes (or globals)".
>
> 3. The :: solution actually does not "need new syntax". It just needs us
> to allow $: in global names. Sure, you can call it a "syntax change" -
> but it is very, very small.
>
> regards, Göran
>

Dan Ingalls

Re: Name spaces in Spoon

In reply to this post by Göran Krampe

Hi, Guys -

Just didn't want to miss out on the fun ;-)...

>"Alejandro F. Reimondo" <[hidden email]> wrote:
> > What do you think about sending the name
>> as message...
>> MyGlobalContext::ThisClass
>> becomes:
>> MyGlobalContext ThisClass
>> the global context (aNameSpace, anEnvironment
>> or SystemDictionary)
>> can respond to the message returning the real
>> object (or via dnu build a method to return it)
>> Using this "trick" we do not need new syntax
> > and the solution is solved as usual (sending messages).

...and [hidden email] replied...
>Just wish to note that this approach was indeed tested IIRC in the
>3.3modules code, and if my memory serves me right Dan proposed it - but
>I am not sure. Personally I was hesitant at the time, and still is.

Yes, 'twas I. Here's what I liked and still do like about it: it is a message-based
interface to independent modules. I learned a lot from dealing with the direct
links in the superclass chain and global variables, when trying to get the full
advantage out of imageSegment-based modules.
[We can chat another time about the virtues of making superclass pointers
also be message-based rather than direct pointers].

>A few comments:
>
>1. It would move the binding time to runtime instead of compile time (or
>if you prefer to call it "code install"-time).

Yes. In the Environments rewrite, the modules were first-class objects,
pointed at just like other globals are now. The class references were
made by sending the class name as a selector to the module. This
introduces a message send, but it's the kind that most VMs do
blindingly fast.

> I can probably imagine
>both pros and cons with that. It is a big change.

Let me call your attention to a couple of "pros" that I consider to be
quite compelling...

1. With this architecture it is not only possible, but trivially simple
and atomically fast to execute, eg,
OldFiles := Files. Files := FlowVers2.
One bytecode, and every access to the File module now
goes to the new package under test. Obviously if something
goes wrong, order is restored with
Files := OldFiles.

2. I have always felt that if things are structured right, then "uninstall"
is already provided by the garbage collector. When you are ready to
get rid of the old file system, then
Files := FlowVers2.
does the job clean and fast because none of the global references
are direct.

Both of these are valuable, and they're not simple in many
competing architectures. Or to put it another way, competitors
should be evaluated with these desiderata in mind.

Just as we hope with Spoon, or any other modular build scheme,
to build up a system from a clean load of packages, if the modules
behave right, you should be able *equally simply* to get back
to the kernel by discard methods that do little else than store nil.

Finally, part of my motivation in all this was to establish criteria
that would allow the modules to be stored as image segments
so that the load process could be blindingly fast. For example,
back when the VM-Construction category was a quarter megabyte
it loaded in less than 100 milliseconds done this way.

>2. In my personal opinion it is less readable than
>MyGlobalContext::ThisClass. It blends into the rest of the code so that
>the reference itself doesn't "stand out"

Well, if we want it to stand out, that's easy enough. It would be
reasonable to highlight all globals and in this case that would
extend to both parts of a package reference.

> It also deviates from the
>"words beginning with capitals refer to classes (or globals)".

Well, we're doing something new, so something has to change.
I kind of like the convention of capitalized messages being
global and inter-module accesses.

>3. The :: solution actually does not "need new syntax". It just needs us
>to allow $: in global names. Sure, you can call it a "syntax change" -
>but it is very, very small.

I'll grant you that. Now we just need to convince ourselves that it's better.

Of course any system-wide change like this is a bit scary to contemplate.
But at one time I can vouch for the fact that I had a single method working
that not only changed every global reference so it worked that way, but
also established the kind of hierarchical SystemDictionary that Ralph
refers to (based on heuristics gleaned from the statistics of inter-class
references). If we get serious about doing this again and want to experiment
with it in a running system as well as doing it bottom-up with Spoon, I'd be
happy to guide people through the reorganizeEverything method that
accomplished this.

I think much was right about Environmnents, but
i think I agree with a criticism Mike Rueger once voiced that the modules
should be as simple as possible, and that building in a hierarchy is
probably not the right thing to do.

- Dan

keith1y

Re: Name spaces in Spoon

In reply to this post by Michael Latta

The solutions discussed here only seem to solve one minor naming problem
rather than a proposal that could bring the community a powerful coding
and problem solving paradigm.

I remember Dave Simmons talking a lot about namespaces. One of the
benefits of his idea was that if namespaces apply on a per method basis
then you have a strategy for solving the fragile baseclass problem.

If you import a class or framework module or whatever into the namespace
that scopes your project and apply further methods bound to that
namespace only to fix or tweak that class, you can do whatever you need
without accidentally breaking anything for other clients of the said module.

Ruby and Javascript coders do this fixing tweaking all the time because
they know that any additions to the "environment" (I always add eachDo
iterator to Array in javascript) are limited in scope to the web page or
script that they are writing. Module/Framework writers have to think
about these things more carefully. It seems that a most common way of
achieving this is through half decent documentation (auto generated etc)
that allows users of a framework to know what is there and what not to
step on, and their tools may warn of such things at compile/load time.
This doesnt really work for us since squeakers don't seem to bother so
much with api documentation.

I was surprised to find that Laszlo defines graphical elements using xml
and any <view id="myView"></view> such elements that have an id
attribute results in a global being defined that you can access myView.
This has to be the worst case scenario if I want to import or paste a
component from someone else that may very easily clash. So there are
still folks out there getting this really wrong.

just my 2p

Keith

___________________________________________________________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

Keith Hodges-2

Re: Name spaces in Spoon

In reply to this post by Michael Latta

The solutions discussed here only seem to solve one minor naming problem
rather than a proposal that could bring the community a powerful coding
and problem solving paradigm.

I remember Dave Simmons talking a lot about namespaces. One of the
benefits of his idea was that if namespaces apply on a per method basis
then you have a strategy for solving the fragile baseclass problem.

If you import a class or framework module or whatever into the namespace
that scopes your project and apply further methods bound to that
namespace only to fix or tweak that class, you can do whatever you need
without accidentally breaking anything for other clients of the said module.

Ruby and Javascript coders do this fixing tweaking all the time because
they know that any additions to the "environment" (I always add eachDo
iterator to Array in javascript) are limited in scope to the web page or
script that they are writing. Module/Framework writers have to think
about these things more carefully. It seems that a most common way of
achieving this is through half decent documentation (auto generated etc)
that allows users of a framework to know what is there and what not to
step on, and their tools may warn of such things at compile/load time.
This doesnt really work for us since squeakers don't seem to bother so
much with api documentation.

I was surprised to find that Laszlo defines graphical elements using xml
and any <view id="myView"></view> such elements that have an id
attribute results in a global being defined that you can access myView.
This has to be the worst case scenario if I want to import or paste a
component from someone else that may very easily clash. So there are
still folks out there getting this really wrong.

just my 2p

Keith

___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

Andreas.Raab

Re: Name spaces in Spoon

In reply to this post by Dan Ingalls

Dan Ingalls wrote:
> Yes, 'twas I. Here's what I liked and still do like about it: it is a message-based
> interface to independent modules. I learned a lot from dealing with the direct
> links in the superclass chain and global variables, when trying to get the full
> advantage out of imageSegment-based modules.

You get very similar advantages when you consider all references to
"outside" globals be really definitions inside the module's namespace
itself. In other words, if module Foo would use "Array new" it would
really mean "Foo::Array" (e.g., the value of #Array inside the module
Foo) and you could populate (parametrize) that via, say "Foo::Array :=
Collections::Array" etc. This has the added advantage that there is no
true "global" access to anything (e.g., no ambient authority beyound
what was explicitly given to the module) and that multiple modules can
co-exist with different parametrizations.

> Let me call your attention to a couple of "pros" that I consider to be
> quite compelling...
>
> 1. With this architecture it is not only possible, but trivially simple
> and atomically fast to execute, eg,
> OldFiles := Files. Files := FlowVers2.
> One bytecode, and every access to the File module now
> goes to the new package under test. Obviously if something
> goes wrong, order is restored with
> Files := OldFiles.
>
> 2. I have always felt that if things are structured right, then "uninstall"
> is already provided by the garbage collector. When you are ready to
> get rid of the old file system, then
> Files := FlowVers2.
> does the job clean and fast because none of the global references
> are direct.
>
> Both of these are valuable, and they're not simple in many
> competing architectures. Or to put it another way, competitors
> should be evaluated with these desiderata in mind.

Unless I misunderstand, both would be utterly trivial in the above.
Since all references are defined in the module's namespace you can do 1)
trivially for any module you'd like and 2) falls out naturally too
(unless I'm missing some subtlety).

> Just as we hope with Spoon, or any other modular build scheme,
> to build up a system from a clean load of packages, if the modules
> behave right, you should be able *equally simply* to get back
> to the kernel by discard methods that do little else than store nil.

Right.

> Finally, part of my motivation in all this was to establish criteria
> that would allow the modules to be stored as image segments
> so that the load process could be blindingly fast. For example,
> back when the VM-Construction category was a quarter megabyte
> it loaded in less than 100 milliseconds done this way.

Right.

> I think much was right about Environmnents, but
> i think I agree with a criticism Mike Rueger once voiced that the modules
> should be as simple as possible, and that building in a hierarchy is
> probably not the right thing to do.

Right. In particular name lookup gets messy, even today, if defined in
multiple places (pools, class vars, environment...) - and that is
another reason why I like the :: syntax. One could require that
references to class or pool vars always need to be prefixed so that it's
clear to the user that PrimitiveVertexSize is not defined in Smalltalk
but rather via B3DEngineConstants::PrimitiveVertexSize.

Cheers,
- Andreas

Michael Latta

RE: Name spaces in Spoon

In reply to this post by Keith Hodges-2

The use of markup defined names comes from VB and that tradition. While it
can make things easy for the enterprise developer that is not interested in
architecture or other software engineering issues, it can certainly create
large monoliths.

The idea that you can load a "module" and have it privately extend a shared
class is interesting. It goes a bit against the idea of classes as the
definition of an object's behavior, but has value. It is sort of like the
Objective-C formalism for adding methods to a class being a first class
semantic. You define a thing like a subclass that has methods and it
extends the base class only in those applications where you include that
module.

The downside I see in having call context dependent behavior is that the
reader of the code needs to know the run-time context that will modify the
behavior of the object. The same result can be achieved with a wrapper
object that implements the new methods, and passes on unknown methods to the
delegate. This at least makes it clear there is behavior being introduced.
For example if two loaded modules both defined the same method differently,
things would get very confusing very quickly without a very clear way for
the reader/browser of the code to know which was being applied.

I can see the need to have methods that are defined by different authors
that happen to use the same selector, but are really different methods. As
the size of libraries grows this is more and more likely. I suspect that
method collision is far more likely and more of an issue than class name
collision. Possibly what is needed is method name prefixes more than class
name prefixes?

Michael

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Keith
Hodges
Sent: Friday, May 26, 2006 5:17 PM
To: The general-purpose Squeak developers list
Subject: Re: Name spaces in Spoon

The solutions discussed here only seem to solve one minor naming problem
rather than a proposal that could bring the community a powerful coding
and problem solving paradigm.

I remember Dave Simmons talking a lot about namespaces. One of the
benefits of his idea was that if namespaces apply on a per method basis
then you have a strategy for solving the fragile baseclass problem.

If you import a class or framework module or whatever into the namespace
that scopes your project and apply further methods bound to that
namespace only to fix or tweak that class, you can do whatever you need
without accidentally breaking anything for other clients of the said module.

Ruby and Javascript coders do this fixing tweaking all the time because
they know that any additions to the "environment" (I always add eachDo
iterator to Array in javascript) are limited in scope to the web page or
script that they are writing. Module/Framework writers have to think
about these things more carefully. It seems that a most common way of
achieving this is through half decent documentation (auto generated etc)
that allows users of a framework to know what is there and what not to
step on, and their tools may warn of such things at compile/load time.
This doesnt really work for us since squeakers don't seem to bother so
much with api documentation.

I was surprised to find that Laszlo defines graphical elements using xml
and any <view id="myView"></view> such elements that have an id
attribute results in a global being defined that you can access myView.
This has to be the worst case scenario if I want to import or paste a
component from someone else that may very easily clash. So there are
still folks out there getting this really wrong.

just my 2p

Keith

___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and
ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html