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.