Squeak and Namespaces

Ahoy!

I know this might sound like a naive question... But why haven't we  
implemented namespaces yet?  I'm sure there have been some attempts-  
but what is the status of namespaces in Squeak?

I ask because it seems that, to me, it would be relatively easy to  
implement an intelligent namespace system in Squeak, something we all  
could decide on.  It could even offer backwards compatibility in  
that, for now, all the classes in the image are just part of the  
default namespace, that way nothing gets broken.

Ideas? Thoughts? Maybe a pointer to a discussion where this was  
already hashed out? Thanks!

Regards,
Aaron

http://minnow.cc.gatech.edu/squeak/734

http://minnow.cc.gatech.edu/squeak/727

On Nov 21, 2006, at 17:32 , Aaron Reichow wrote:

> Ahoy!
>
> I know this might sound like a naive question... But why haven't we  
> implemented namespaces yet?  I'm sure there have been some  
> attempts- but what is the status of namespaces in Squeak?

You can download the latest incarnation of Namespaces from Squeakmap

        http://map.squeak.org/package/f88f4752-c4a5-42bf-a613-f7d2a4f48cff

There has been a lot of discussion, but I think most agree now that  
this is such a simple approach that it might be worth adopting. There  
is a presentation somewhere explaining it, I'm sure Göran will dig it  
out if nobody beats him to it.

- Bert -

Hi!

Bert Freudenberg <[hidden email]> wrote:
Really? That would of course be very nice - but so far I haven't really
experienced an overwhelming interest from people holding the rudder (for
3.9 for example). I still think it is a great simple solution though.

> There  
> is a presentation somewhere explaining it, I'm sure Göran will dig it  
> out if nobody beats him to it.

Well, the homepage pointed at from SM has a few writeups, this is the
last one:

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

regards, Göran

PS. Yes, I have a presentation in an image somewhere but it needs a
"presenter" running it.

Hi.

Göran gave a demo of the namespace system at a SWESUG meeting, and its
was clean and easy to understand. You just name your classes as if you
would have prefixed them, like this:

Prefix::ClassName

The tools hide the prefix unless it is needed to disambiguate a name.
There is no need to use the namespace prefixes, the namespace system
works fine together with the existing global namespace.

Would be a good idea to put this into the next release.

Best, Micke

On 11/21/06, Bert Freudenberg <[hidden email]> wrote:

+1

- Bert -

On Nov 28, 2006, at 22:52 , Mikael Kindborg wrote:

+1 more

Ramon Leon
http://onsmalltalk.com 

Please consider an other character, other than the colon. Someone already  
made a mistake when inventing resend.thisAndThat so that the compiler (and  
the user) has to disambiguate the syntax, like in, example.doThisAndThat.

In Smalltalk colons belong to arguments and keywords, not to namespace  
expressions. Remember the white space problem with the minus sign / minus  
binary selector?

Besides of that, here's my +1

/Klaus

P.S. IMO it's overdue that &middot; &ndash; &mdash; &hellip; and friends  
make their way into regular syntax diagrams and parsers,

-  
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

On Tue, 28 Nov 2006 22:55:12 +0100, Bert Freudenberg wrote:

Actually, that is the beauty of the proposal. Colons are already  
allowed unquoted in a symbol. #My::Class is valid right now. In this  
proposal, the compiler knows *nothing* about namespaces. It just  
permits a colon in a global identifier. It's the only syntax change.

- Bert -


On Nov 28, 2006, at 23:30 , Klaus D. Witzel wrote:

On 11/28/06, Klaus D. Witzel <[hidden email]> wrote:
> Please consider an other character, other than the colon. Someone already
> made a mistake when inventing resend.thisAndThat so that the compiler (and
> the user) has to disambiguate the syntax, like in, example.doThisAndThat.
>
> In Smalltalk colons belong to arguments and keywords, not to namespace
> expressions. Remember the white space problem with the minus sign / minus
> binary selector?
>
> Besides of that, here's my +1

+1

--
Jason Rogers

"Where there is no vision, the people perish..."
    Proverbs 29:18

Mikael Kindborg wrote:

> Hi.
>
> Göran gave a demo of the namespace system at a SWESUG meeting, and its
> was clean and easy to understand.

> ...

> Would be a good idea to put this into the next release.
>
> Best, Micke
>
+1

David

Bert Freudenberg wrote:
> Actually, that is the beauty of the proposal. Colons are already allowed
> unquoted in a symbol. #My::Class is valid right now. In this proposal,
> the compiler knows *nothing* about namespaces. It just permits a colon
> in a global identifier. It's the only syntax change.

Is that really true? I haven't looked at the code in a while but Goran
used code that I had originally written and that code most certainly
wasn't just permitting colons in a global identifier.  What it did do
was introducing explicitly scoped variables and the result of Foo::Bar
would depend on what is stored in Foo's scope under the name of #Bar and
not on what is stored under Smalltalk at: #'Foo::Bar'. Of course, these
two can be made the same by using the same association but that's still
quite a bit different from just permitting colons in global names.

Generally speaking, I'm -1 on the proposal, mostly because what the
proposal doesn't achieve is to make a real step towards enabling
scalability of development (which to me is really what we're after).
That's because the *author* of some code still needs to find unique
names (prefixes) that do not conflict with the rest of the world and
that a "change of prefix" becomes very, very expensive because it's
literally like renaming all of the classes at once (and consequently
breaking all of the code that uses any name from that "prefix space").

So basically you're trading the probability of conflicts (reduced due to
the increased length in names) with the severity of conflicts (increased
since changing the prefix is more expensive). It's an incremental
approach that shifts tradeoffs but doesn't do anything to address the
problem on a more fundamental basis (in all fairness, Goran never
claimed it did but it's important in this discussion to understand what
this proposal does and doesn't do to assess the impact of a change).

But since it's "only" an incremental shift in tradeoffs I wonder if a
language change (with significant costs for compatibility) is really
justified. It seems to me that the practical gain is fairly minor and
there is little motivation that I can see for anyone with a "serious"
project to adopt this solution given that it will neither be portable
nor backward-compatible. Put on top that the proposal deliberately
doesn't take a stand on any general modularity issues (visibility,
dependencies), then what exactly does one gain?

To me the basic question here is: Is the prefix pattern so pervasive
(and so problematic) that it deserves a special syntactic
representation? Without taking a stab at the "real" problem (scalability
of development) my answer is: No. It's a clever hack but nothing that I
would loose sleep over if it weren't there (and I won't loose sleep over
it being there either but I'd like us to be clear about what we're
trying to achieve with adopting it).

Cheers,
   - Andreas

I agree with Andreas. Funny but true.
This is so important that you noticed that I even break my silence....

Stef

PS: I have been working with VW recently and I really found  
namespaces getting in my way all the time. Also the integration of  
namespaces
in VW is badly supported at the refactoring level and other tools. So  
this is often a pain.

PSPS: We have been thinking a lot of this issue and I'm even  
unsatisfied with what I thought would be interesting: package import  
level
where each class live happily in a package (the package resolves the  
import) and the programmer does not see namespace except at the boundary
when declaring imports but I finally do not like that solution  
because the cost is too big for the gain. I would like to see a real  
system
develop with it and see the pros and cons before really been sure. So  
certainly a PhD topic.


On 29 nov. 06, at 09:14, Andreas Raab wrote:

On Wed, 29 Nov 2006 09:42:39 +0100, stephane ducasse wrote:

> I agree with Andreas. Funny but true.
> This is so important that you noticed that I even break my silence....

:)

Mind to address your requirements from the view of ClassBoxes?

/Klaus

P.S. *package* is just another word for *problem* ;-)

Hi Aaron,

as can already seen from this thread, (Squeak times: Namespaces) seems to  
be not easy because multiple requirements may clash.

We should define how namespaces work, my suggestion:

- concept: a class defines a namespace, is authoritative
- atoms: classes and [parts of] their state are atomic namespaces
  >= "namestate"
- composition: a namespace is a container with 1:n components, a namestate  
is a component with 1:1 container
- uniqueness: a namestate and its full name are unique, its atomic name  
*must* not

There *should* be some syntactical emphasis so that the developer (and  
Shout) can understand!

Motivation for syntax: we say SmallInteger and LargeInteger to subclasses  
of Integer and obviously prefer the opposite direction for a namespace  
hierarchy. Let's replace the suggested :: by a legitimate binary message

  Morphic >~ View
  Tweak >~ View
  System >~ Default >~ Compiler
  My >~ Terrific >~ Compiler

The compiler *should* be extendable by a namespace/namestate  
implementation. Of course the implementation of #>~ depends on the  
run-time used (VW, Squeak, etc) and the default implementation is DNU (for  
Xtreme speed of development ;-)

And Class#>~ can be overridden in support of specialized namestate  
resolution during fileIn and accept (I mean alt-s in the browser).

My CHF 0.05 :)

/Klaus

P.S. in the above, nothing much is new.

P.P.S. if I had a whish free then I'd like to drag'n'drop namestate in the  
browser (Andreas' step towards enabling scalability of development).

On Tue, 21 Nov 2006 17:32:10 +0100, Aaron Reichow <[hidden email]>  
wrote:

Hi!

Btw, if any of you haven't read my last little article on my proposal,
here it is, it is short and funny :) :

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

> Bert Freudenberg wrote:
>> Actually, that is the beauty of the proposal. Colons are already allowed
>> unquoted in a symbol. #My::Class is valid right now. In this proposal,
>> the compiler knows *nothing* about namespaces. It just permits a colon
>> in a global identifier. It's the only syntax change.
>
> Is that really true? I haven't looked at the code in a while but Goran

I haven't either - so I will begin by replying from memory - it might be
slightly incorrect. I can check later tonight.

> used code that I had originally written and that code most certainly
> wasn't just permitting colons in a global identifier.  What it did do
> was introducing explicitly scoped variables and the result of Foo::Bar
> would depend on what is stored in Foo's scope under the name of #Bar and
> not on what is stored under Smalltalk at: #'Foo::Bar'.

IIRC what we did was to add as you say a new "explicitly scoped variable"
in the actual parser BUT the actual lookup implementation used when that
method is triggered was implemented as "what is stored under Smalltalk at:
#'Foo::Bar'".

The instances of Namespace in my code behave like Dictionaries so if you
have a Namespace 'Foo' then:

Foo == (Smalltalk at: #Foo)  "the Namespace itself is a global"

(Foo at: #Bar) == Smalltalk at: #'Foo::Bar' "Namespace>>at: will simple
look it up in Smalltalk so it is only emulating being a Dictionary"

...and of course:

Foo::Bar == (Smalltalk at: #'Foo::Bar')

In fact, I believe it was you Andreas that strongly suggested I should do
it this way or take on a world of hurt. :)

> Of course, these
> two can be made the same by using the same association but that's still
> quite a bit different from just permitting colons in global names.

It uses the same association.

> Generally speaking, I'm -1 on the proposal, mostly because what the
> proposal doesn't achieve is to make a real step towards enabling
> scalability of development (which to me is really what we're after).
> That's because the *author* of some code still needs to find unique
> names (prefixes) that do not conflict with the rest of the world and

Two "solutions" to this:

1. Let us make SM track prefixes.
2. Make it really easy to "remap" one namespace to another when loading code.

The last idea is that the system can check for such "remaps" when filing
in code (or similar) and if there is one (say from SM->NewSM) it simple
asks "Code uses Namespace 'SM', should I put this in SM or in the
alternative NewSM?"

> that a "change of prefix" becomes very, very expensive because it's
> literally like renaming all of the classes at once (and consequently
> breaking all of the code that uses any name from that "prefix space").

Yes, it is literally renaming - but it still feels quite easily doable.

> So basically you're trading the probability of conflicts (reduced due to
> the increased length in names) with the severity of conflicts (increased
> since changing the prefix is more expensive).

Ehm, how can it be more expensive? You mean compared to changing a single
clashing class name?

> It's an incremental
> approach that shifts tradeoffs but doesn't do anything to address the
> problem on a more fundamental basis (in all fairness, Goran never
> claimed it did but it's important in this discussion to understand what
> this proposal does and doesn't do to assess the impact of a change).

Indeed it is not a "Grand Scheme" - but I still find it to be a useful
next step that enables more advanced mechanisms as we learn and go
forward.

It still is *compile time binding*. It does not change the fundamental
mechanism (still uses the Smalltalk system dict) but it *does* introduce
the concept Namespace (and class) and "reifies" them as globals.

And it *does* enable experimentation with prefix hiding (as I do in the
tools part) or even experimenting with explicit imports (which I detest -
and even Stephane now seems to think is a bad idea - but hey, feel free to
play around).

> But since it's "only" an incremental shift in tradeoffs I wonder if a
> language change (with significant costs for compatibility) is really
> justified.

Is the "language change" really of that kind? You can already have global
names with : in them (which is funny) but if you try using that for a
class you will get into trouble - a bug IIRC. So the small changes could
even be considered to be a bug fix. :)

And new code will work fine in an old Squeak - as long as you add those
trivial tweaks (2-3 method changes IIRC) needed to have global names with
:: in them.

> It seems to me that the practical gain is fairly minor and
> there is little motivation that I can see for anyone with a "serious"
> project to adopt this solution given that it will neither be portable
> nor backward-compatible. Put on top that the proposal deliberately
> doesn't take a stand on any general modularity issues (visibility,
> dependencies), then what exactly does one gain?

I agree that it deliberately does not involve dependencies, and only a
little bit about visibility (the tool extensions I did have some
visibility mechanisms) - because I think we can first add the *basic*
notion of "named buckets" (=Namespace) and the *basic* syntax - without
blending those two issues into the pot.

If someone then would want to tie these Namespaces into dependencies,
imports, modularity etc - then that is IMHO a "next step".

> To me the basic question here is: Is the prefix pattern so pervasive
> (and so problematic) that it deserves a special syntactic
> representation? Without taking a stab at the "real" problem (scalability
> of development) my answer is: No. It's a clever hack but nothing that I
> would loose sleep over if it weren't there (and I won't loose sleep over
> it being there either but I'd like us to be clear about what we're
> trying to achieve with adopting it).

I more or less agree. :-o Class collisions is NOT a large problem in
Squeak - dependencies and modularity on the other hand ARE increasingly
so.

BUT... if we intend to try to tackle those two beasts on the language
level (instead of say SM or MC level), then perhaps a Namespace "notion"
is a first step.

And it doesn't seem to be a dangerous step either. But it will enable
experimentation.

To summarise - it reifies prefixes and makes them concrete and easy to
manipulate, and easy to spot. That is all, and since we *have* these
things already (prefixes) - then making them tangible, concrete, real
objects seems like a useful thing to do.

> Cheers,
>    - Andreas

regards, Göran

PS. I had more or less given up on ever seeing the code in official
Squeak, since there always seem to be people against it. I was happily
surprised by Bert's post, but I don't expect nor dare to hope :) that it
ever will enter Squeak. But I still think it is a good, neat step and if
"the people in charge" decide that we will include it I gladly whip the
code some more. It is very small btw, feel free to look and read class
comments.

Andreas Raab <[hidden email]> writes:
> Generally speaking, I'm -1 on the proposal, mostly because what the
> proposal doesn't achieve is to make a real step towards enabling
> scalability of development (which to me is really what we're
> after). That's because the *author* of some code still needs to find
> unique names (prefixes) that do not conflict with the rest of the
> world and that a "change of prefix" becomes very, very expensive
> because it's literally like renaming all of the classes at once (and
> consequently breaking all of the code that uses any name from that
> "prefix space").

It's a good observation.  Nonetheless, a hierarchical global namespace
seems a good step forward over a flat global namespace.  I do not know
about *this* system, but in general I would love if global variables
and classes had long hierarchical names.  Using the existing class
categories would seem great for that.

Right now, responsible programmers already fake a hierarchical
namespace by putting prefixes in front of all their global names.  At
the very least, it would be nice to support this practice in the
programming language.  Ideally, you can even use long names
("Monticello") instead of short prefixes ("MC") and thus greatly
reduce the chance of conflicts.

In practice, I bet it's not so hard to pick prefixes that are unique
in the contexts the package will be used in.  Most of the time, you
can just use the name of the project, which you have surely already
gone to some efforts to try and make unique.  If nothing else, all the
open-source projects would benefit!


Finally, keep in mind what the great naming systems you describe for
the future would look like.  They will probably still have path-based
identifiers!  The only difference from hierarchical names would likely
be that the path can start from somewhere other than a single global
root.  Thus, a flexible hierarchical-naming system would seem like a
good basis for the kind of naming system you are thinking about.  (In
particular, you would want Foo::Bar to really mean "Bar" within
"Foo"....)



-Lex

+1

I like Goran solution. Its true that only  fixes the "prefix" problem  and not the "namespace" problem, as Andreas pointed out. But to me that is not a bad thing. its one step further to make Squeak a little more comfortable.

Regards,
Hernán




--
Saludos,
Hernán

There's a heuristic that says incremental wins are good, but there are
cases that don't apply. ("The world is better off without Saddam Hussein
in power, no?") How do we know that this isn't leading the kind of "half
a loaf" (non-)solution that I tend to worry about?

Guy Steele once told me that the first thing he tries to get right about
a language is the namespace. "Get that wrong and you'll never recover."

I like Andreas' way of comparing what the proposal does to the cost of
programmer changes. Determining whether his analysis is correct depends,
I think, on what the proposal is actually doing, no?  I think it's
possible to implement it in such a way that changes scale appropriately,
but it is not yet clear to me that the code actually does things that way.
-Howard

Hernan Tylim wrote:
--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724