Squeak and Namespaces

Aha.  Ok, I missed this part somehow.  So the Kernel::Dictionary scenario
doesn't have to happen (as long as we keep it simple), but the issue is
still there for other more popular packages.  I guess I just see Smalltalk
as it is right now as as beautiful as it can get. :)

_________________________________________________________________
Get the latest Windows Live Messenger 8.1 Beta version. Join now.
http://ideas.live.com

Aha.  Ok, I missed this part somehow.  So the Kernel::Dictionary scenario
doesn't have to happen (as long as we keep it simple), but the issue is
still there for other more popular packages.  I guess I just see Smalltalk
as it is right now as as beautiful as it can get. :)

_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

Ok.

> > So conclusion simple namespaces do not help avoid clashes.
>
>Yes they do.
>

What (I think) he is saying is:  Most people are prefixing anyway (I always
do), so if you get a clash then you probably tried to make another SPUser.  
So just putting a couple of colons between SP and User isn't going to save
you in that case.

>Manually prefixing classes to prevent name clashes, and being forced to use
>those long names when the tools could do it for us, and hide it from us in
>the browsers.
>

It isn't going to hide it from you.  It will hide the prefix *so long as no
other class in the system has that name*.  As soon as *one* duplication
happens *all* ambiguous classes will be fully prefixed in the source code.  
In the entire image.

And we can't do it the way you suggest anyway (well we could but it would be
even more complicated) because if the classes are fully qualified every time
(they are) and the browser hides all but the actual class every time (it
does not) then how do we know from looking at someone else's code which
actual class they are talking about?  Seeing colons is the indicator that
there are two or more classes in the image with the same base name.

>And again I'll say, it's a tiny fix that automates something that we do
>manually now anyway, and is a pain in the ass.  I don't like prefixing my
>class names, it's ugly.  I pump objects across web services to .Net, where
>my class names are nice and pretty and simple, because .Net supports
>namespaces, yet I'm forced to uglify them on the Squeak side because I
>can't
>name a class something simple in Squeak and feel even mildly safe about
>doing so.
>

For you it's ugly.  I don't notice it at all (so far).  So what is also
obvious from the traffic on this thread is that some people want it and some
people don't.  So to me that means it should be a loadable module for those
who want it.  And it is.

One thing we could think about here is to make some kind of automated tool
to switch between the two so that we could all be happy.  If you make a
package that uses namespaces and I load it from squeakmap my system could
automatically turn your namespaces into prefixes and vice versa (ok, this
part is hard, but we could just make it manual on package upload).

_________________________________________________________________
MSN Shopping has everything on your holiday list. Get expert picks by style,
age, and price. Try it!
http://shopping.msn.com/content/shp/?ctId=8000,ptnrid=176,ptnrdata=200601&tcode=wlmtagline

> Just to toss in my votes:
>
> 1) I am not sure that SM::Package is an improvement over SMPackage.
> It does not look like a large improvement, anyway.
> -Lex

It's not a large difference, but it makes all the difference in the world to
automated tools supporting the hiding of prefixes.

Ramon Leon
http://onsmalltalk.com 

>From: Göran Krampe <[hidden email]>
>Reply-To: [hidden email], The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: Squeak and Namespaces
>Date: Fri, 1 Dec 2006 08:49:59 +0100 (CET)
>

I saw in one of your earlier messages that you feel insane sometimes.  I
wouldn't take all this so personal.  I don't think you are crazy.  I think
you are a great coder with a nice solution.  I just disagree with putting
this particular one in by default.

_________________________________________________________________
MSN Shopping has everything on your holiday list. Get expert picks by style,
age, and price. Try it!
http://shopping.msn.com/content/shp/?ctId=8000,ptnrid=176,ptnrdata=200601&tcode=wlmtagline

Well, I would just find seeing that everywhere in my smalltalk code very
ugly.  And looks of code do matter.  We are trained from a young age not to
look at ugly things more then we must.

>Really? A huge pain? I agree that Traits are great etc, but I would not
>say that we had "huge pain" before we got them.
>

Yes, the inheritance model without them has some real problems.  And finding
a solution is tough.  C++'s multiple inheritance?  Too complicated.  Java's
interfaces?  Too much work and code duplication.  So now smalltalk has a
solution, and IMO the best one.

_________________________________________________________________
Talk now to your Hotmail contacts with Windows Live Messenger.
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get.live.com/messenger/overview

They allow positional arguments?  Why?  Or are you talking about the <>
stuff.

>Sure, weird and uncommon must be bad. Let's just turn Squeak/Smalltalk
>into one of the "other languages" by emulating how they work - that seems
>better - let's add imports and... hmmm, we could even start putting the
>classes in files on disk - then it would be much simpler to find those
>import statements! :)
>

But you are doing almost exactly what C++ does (a namespace in C++ just gets
stuck on the front of the symbol).  The only difference is that C++ has a
bunch of complicated import statements for compile time convenience.  So I
wouldn't say it is such a different concept.

_________________________________________________________________
Get the latest Windows Live Messenger 8.1 Beta version. Join now.
http://ideas.live.com

Hi all!

Lex Spoon <[hidden email]> wrote:
> Just to toss in my votes:
>
> 1) I am not sure that SM::Package is an improvement over SMPackage.
> It does not look like a large improvement, anyway.

Not sure what you mean with "improvement". Visually?
 
> 2) A general hierarchy is an improvement over one-level.  If you have
> a project with 1000 classes in it, then you need multiple namespaces
> within your project, and you want to group them under an umbrella
> identifier of your project.  Without hieriarchical names, you will
> have to invent a prefix for all your namespace names....

I actually disagree. I don't think you need multiple namespaces if you
have 1000 classes in the *same Project*. 1000 classes doesn't equal such
a large team in practice - perhaps 10 developers? Not that hard to keep
names unique IMHO. Remember that this isn't java - we don't need
"namespaces" just to organize our classes - we have Categories for that.

Squeak itself is more than 1000 classes and we haven't seen any real
issue in keeping the names within base Squeak unique, have we?

Finally - just because we allow Foo::Bar does not necessarily mean we
want to have a "real" hierarchy and allow Foo::Boo::Bar. In fact, I
would like to stay away from that and just use "buckets" - call it a one
level hierarchy if you wish. Again, we have Categories for organisation
- I don't see the need for having multiple levels of namespaces. And I
really would like to understand exactly what semantics people think it
has - it is not obvious to me as I have posted a few times now.

regards, Göran

Hi!

"J J" <[hidden email]> wrote:
> >From: "Ramon Leon" <[hidden email]>
 > > > So conclusion simple namespaces do not help avoid clashes.
> >
> >Yes they do.
>
> What (I think) he is saying is:  Most people are prefixing anyway (I always
> do), so if you get a clash then you probably tried to make another SPUser.  
> So just putting a couple of colons between SP and User isn't going to save
> you in that case.

I agree - just like in Java, if I create
se.blabla.booboo.Whatchamacallit and you actually create the exact same
- then sure, we get a conflict because we used the same namespace - of
course!

The conclusion is false - they *do* help avoid clashes, but sure they
don't prevent clashes from ever being even theoretically possible. And
so? If prefixing didn't actually help avoid clashes - then why do you
think people use prefixes in the first place?

> >Manually prefixing classes to prevent name clashes, and being forced to use
> >those long names when the tools could do it for us, and hide it from us in
> >the browsers.
> >
>
> It isn't going to hide it from you.  It will hide the prefix *so long as no
> other class in the system has that name*.

Or any other policy is in effect - like for example if the name is
defined "locally" etc.

> As soon as *one* duplication
> happens *all* ambiguous classes will be fully prefixed in the source code.  
> In the entire image.

Again, modulo any "special" policies like the local policy yes. You make
it sound like we would see *more* prefixes using my solution than with
the current custom of prefixing. It is the other way around you know. :)

> And we can't do it the way you suggest anyway (well we could but it would be
> even more complicated) because if the classes are fully qualified every time
> (they are) and the browser hides all but the actual class every time (it
> does not)

Not *every time* but theory suggests that they would hide them in 99% of
the cases.

> then how do we know from looking at someone else's code which
> actual class they are talking about?  Seeing colons is the indicator that
> there are two or more classes in the image with the same base name.

You lost me. Yes, seeing Foo::Bar indicates that Bar is not unique in
your image.

The problem with having a Namespace solution as a loadable module is
pretty obvious.
Those who use it for their packages will inevitable "force it" upon
their users (of their packages).

I just don't think people will use it if is not "standard".

> One thing we could think about here is to make some kind of automated tool
> to switch between the two so that we could all be happy.  If you make a
> package that uses namespaces and I load it from squeakmap my system could
> automatically turn your namespaces into prefixes and vice versa (ok, this
> part is hard, but we could just make it manual on package upload).

Well, it is not impossible I guess - but the complexity sounds like it
would really diminish the value of this solution. Suddenly it does not
sound worth it to me.

regards, Göran

Hi!

"J J" <[hidden email]> wrote:
Ehm, everywhere? I am not sure you have understood this proposal - the
likely effect is that you will almost NEVER see any of those :: in
actual code. You will see them in class definitions though.

Recall that they are only showed when there is a *conflict*.

> >Really? A huge pain? I agree that Traits are great etc, but I would not
> >say that we had "huge pain" before we got them.
>
> Yes, the inheritance model without them has some real problems.  And finding
> a solution is tough.  C++'s multiple inheritance?  Too complicated.  Java's
> interfaces?  Too much work and code duplication.  So now smalltalk has a
> solution, and IMO the best one.

As Avi posted - are you basing this on experience? Because most
experienced Smalltalkers have almost never felt any pressing need for
them. Sure, they are nifty - and they can improve on design - but a
"huge pain"? Nah.

regards, Göran

My point was was that after a few years of use conflicts will be everywhere.
  But I suppose the tools can be set up to, for example, not show the ::
ever but do it on mouse-over or something.  I guess I could live with that.

>As Avi posted - are you basing this on experience? Because most
>experienced Smalltalkers have almost never felt any pressing need for
>them. Sure, they are nifty - and they can improve on design - but a
>"huge pain"? Nah.
>

Ok, they don't solve a huge pain as in something that bites us every day.  
But more of a huge pain as in a fundamental problem with OO systems when
they get larger.  And since one of the main points of OO development was to
be able to develop very large systems, I count that as a huge pain.

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

They help avoid prefixes exactly as much as prefixing does.  No more, no
less.  What we are basically talking about is manual prefixing with a few
letters vs. manual prefixing with (probably) a few letters plus two colons,
plus the posibility to hide the prefix with the colon solution.

So the two options are almost the same except the colon solution makes the
classes uglier, but there are more options about what to do with the
prefixes since the tools can detect them.

>You lost me. Yes, seeing Foo::Bar indicates that Bar is not unique in
>your image.
>

I was responding to the assertion that we would only ever see the short
name.  But the system as I understood (and you seem to be describing here
again) it would show all conflicting names explicitly and the example given
had lots of conflicting names.  But I guess it is a moot point.  Once the
tools know it there are more options (e.g. if I am in a certain namespace
hide all references to that namespace, just show references outside of it
for conflicting classes).

_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

Hi!

"J J" <[hidden email]> wrote:
Of course! :) Prefixes are just as "valid" namespaces as any other
namespaces solution is.
They are ALL about having a named space and putting names in there.
AFAIK.

> letters vs. manual prefixing with (probably) a few letters plus two colons,
> plus the posibility to hide the prefix with the colon solution.
>
> So the two options are almost the same except the colon solution makes the
> classes uglier, but there are more options about what to do with the
> prefixes since the tools can detect them.

This "ugliness" notion is interesting since I personally think
WAComponent is uglier than Component etc.

> >You lost me. Yes, seeing Foo::Bar indicates that Bar is not unique in
> >your image.
>
> I was responding to the assertion that we would only ever see the short
> name.  But the system as I understood (and you seem to be describing here
> again) it would show all conflicting names explicitly and the example given
> had lots of conflicting names.  But I guess it is a moot point.  Once the

I wonder what situation would give you "lots of conflicting names".
AFAIK it is still pretty uncommon.

And again, even if there ARE 4 projects using say "Component" - it is
not typically so that you happen to have all 4 in your image at the same
time.

regards, Göran

As far as what is the best solution for namespaces, here is my personal
pick:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-November/111762.html

No new syntax (I think), and it gives a lot more then just prefixes.

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

On Dec 2, 2006, at 22:32 , J J wrote:

> As far as what is the best solution for namespaces, here is my  
> personal pick:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- 
> November/111762.html
>
> No new syntax (I think), and it gives a lot more then just prefixes.

This sounds like it would be realizable with Squeak's #environment  
hooks. Are you up to implementing a prototype so we could try it?

- Bert -

This is pretty good.

FWIW, I am totally against adding new prefixes.  All classes already  
have an identifier that resolves them to a "package" and that is  
category.  So the long name of Object is really Kernel-
Objects:Object.  Using the one class dictionary per package strategy  
mentioned, I think the compiler should simply prompt the user with a  
menu like:

Ambiguous reference to class "Widget"
Foo:Widget
Bar:Widget.

It should remember this first time and resolve it that way from now  
on much the way it spots new message selectors and remembers that you  
do indeed mean that name.  For the rare instance when one needs to  
reference two classes with the same name in different packages, one  
can type the optional package prefix.

That would solve the problem nicely from a user's perspective.  How  
to make this work is left as an exercise for the implementer. :-)

-Todd Blanchard

On Dec 2, 2006, at 1:32 PM, J J wrote:

I find WAComponent and Component about the same, but WA::Component I find
unappealing.

>I wonder what situation would give you "lots of conflicting names".
>AFAIK it is still pretty uncommon.
>

But in the solution I was responding to there were about 5 classes called
"User".

>And again, even if there ARE 4 projects using say "Component" - it is
>not typically so that you happen to have all 4 in your image at the same
>time.
>

I'm confused here.  You mean all 4 in different namespaces?  Because if so,
then I can give you an example.  I use Pier.  It pulls in Magritte and
Seaside.  All three have a Component class.

_________________________________________________________________
Fixing up the home? Live Search can help
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG

[hidden email] writes:
> Lex Spoon <[hidden email]> wrote:
> > Just to toss in my votes:
> >
> > 1) I am not sure that SM::Package is an improvement over SMPackage.
> > It does not look like a large improvement, anyway.
>
> Not sure what you mean with "improvement". Visually?

The onus on the proposer to say how this is an improvement.  Thus far
I do not see it.

I see factors in each direction that are close to a wash.  Visually it
is uglier, IMHO, though it is a matter of taste.  Regarding ambiguity,
it has the advantage of decreasing ambiguity, but it pays two
characters per name to accomplish this, and I am not sure it adds much
in practice.  In practice, the prefix is almost always all the leading
capital letters except the last; the only exceptions I can think of
are classes with protocols in their name (e.g., HTTPSocket).  Aside
from that, if you are going to spend two characters, can't you just as
well add two *meaningful* characters, e.g. SqMp instead of SM?  This
would appear to disambiguate even further.


The tool benefits you have proposed are interesting but tricky, and
are not a clear win.  They are especially tricky when you consider
code appears in places outside of the normal browsers.  This happens
all the time in Smalltalk....




You are agreeing we should have sub-categories, but proposing that we
should accomplish this by having two different kinds of categories in
the system.  Isn't that a pity, though?  Why not stick with one
categorization scheme for names?

We currently have a single categorization scheme.  It appears
practical to evolve that existing scheme into a *single* scheme for
using hierarchical names to disambiguate.  Given this practical
strategy as an ultimate goal, it seems a pity to move in a different
direction.


Overall, it is inevitable that some of the feel Frank describes is
going to get worse when we add hierarchical names of any kind.  Let us
try to have a clear win before we adopt something that has these
definite minuses.

-Lex

Unfortunately no.  I have no time at all right now (new job, long hours,
long train ride, new child).  But it seems like that is a problem we all
have.

I know on mozilla they do a bounty system to get work done.  I know it has
been suggested before, but who all would be willing to put up at least $20
for something that needs to be done in smalltalk?  And the more jump in, the
less it would cost per person.  $10 from 100 people might get some work done
and might be easier to get then $20 from 50 people.

I know there has been concerns voiced about what happens if the code isn't
accepted, etc., but other groups do it.  Lets just try it and see how it
goes.

_________________________________________________________________
Talk now to your Hotmail contacts with Windows Live Messenger.
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get.live.com/messenger/overview

I still can't decide whether I want to separate the import mechanism into a separate class, so that every class has a private list of namespace imports. So far I've come to the conclusion that this would be tightly coupled, 1 to 1 with Namespace so they may as well be the same class.

This allows security: There can be multiple root namespaces each with a different set of accessable classes and shared variables. It is also allows imports to other namespaces, so that an individual namespace can be granted access to a particular class or namespace which it otherwise wouldn't have access to. If there are any obvious security flaws here, please point them out to me :-).

This would require a bit of re-thinking about how the development tools are used. I'd probably make a "Namespace browser", and you'd have to open workspaces, browsers, etc from that so that the workspaces etc have access to classes and shared variables from that Namespace.

Finally, classes will no longer have access to the #Smalltalk SystemDictionary, for obvious security reasons. There are a few notes in the wiki at http://www.squeaksource.com/SecureSqueak.html . I'll put the code there when it actually does something useful.

Michael.