My namespace proposal described in Yet Another Try

Hi folks!

I just typed this in, longish but hopefully enlightening, forgive me for
any typos etc.

regards, Göran
------------
I agree, syntax is not really important. And we have already discussed it
AT LENGHT at earlier occasions. To all of you out there that think this is
the *first* Namespace-discussion on Squeak-dev - you have no idea... :)

Compile time binding vs late binding:
Currently we have compile time binding of class names, I think moving away
from that as the "default" is too much of a change.
And at the times we want to do late binding we can already use obvious
Smalltalk code (in both our proposals): MyNamespace at: #Array

Let me try to explain a bit about my proposed solution (and yes, it is on
SqueakMap and *works* almost completely, updated for 3.9 IIRC):

I have written about it on numerous occasions and every time it feels like
a lot of people either misunderstand it, don't think it *is* a namespace
solution at all, don't even try to understand it or all of the above. :) I
am not sure why, but I think it has at least *partially* to do with people
being so fixated on how "other languages do it" that they can't even begin
to consider an alternative approach. If you read this, please try to open
up your mind and consider that there ARE other ways to do it. :)

Ok, (rubbing head to come up with the ultimate pedagogical approach),
let's begin with a few "Intentions" with this proposal:

- Simple. I mean, dead simple. :)
- Backwards compatible. Tools should work etc etc.
- Not disrupt the "feel" of Smalltalk. Read more below.

Now... Michael is IMHO implementing a rather "regular" namespace solution,
as so many others have done or tried doing over the years. That may be
fine - and from what I know he is doing it as part of a larger project so
he probably have good reasons for its design. My proposal is solely aimed
at being a lightweight-just-enough-solution only aimed at Squeak and its
community and not rooted in any other project. In other words - there is
NO other use of my code and effort than getting it eventually accepted in
Squeak - otherwise it is totally wasted. ;)

Let's look at "Simple" first. In my proposal I am proposing that we "go
with the flow" and evolve what we already have. What *do* we have then? We
have a shared global space (SystemDictionary) and other spaces created by
various participants in our community (prefixes). Examples are WA for
Seaside, SM for SqueakMap and so on. Let's consider that for a second - we
actually *already have* a Namespace solution in place which works!
Prefixes. I can hear people thinking "Is he on crack or what, that's not
namespaces..." - but I challenge you: Why not?

Just because lots of people over the years have for various reasons
decided to make namespaces==package (or some other concept) does not mean
that a Namespace IS a package or any other source code or deployment
entity. A Namespace is "just a space of names" - a Dictionary simply.
Please agree with me on that. :) A named space that is a cooperatively
maintained set of unique names.

If we agree on this then the scope of problems we are trying to solve is
made much smaller and comprehensible:

- Allowing duplicate names in an image.
- Being able to write short names and read short names.
- Being able to manipulate namespaces like remapping or moving names
between them etc.

It does not deal with deployment units, method overrides, source code
management etc etc!

Now, let's look at the prefixes used today then:

- It is not hierarchical! It is simple "a bunch of named buckets". But
that is exactly what was needed! So saying that namespaces MUST be
hierarchical is ignoring the fact that what we have today actually works.
- Binding is compile time, just as with globals. Hey, WAComponent is of
course also a global, since the solution today is just plain prefixing.

I am proposing:

- Allow "::" (or hey, any other nice separator that we can agree on - it
is NOT that important) in global names. This is a very small change and we
have done it (Andreas and I) and it works.
- Implement class Namespace and let it act just like a Dictionary and let
us create one instance "per prefix" automatically. This is the reification
part of my proposal so that:

        Fruit::Orange == (Smalltalk at: #Fruit) at: #Orange
        Fruit::Orange == Fruit at: #Orange
        Fruit class == Namespace

Thus our namespaces are globals and we can easily do nice dynamic lookup
using "Fruit at: #Orange" if we like. We can also easily check for
Namespaces being there with "Smalltalk at: #Fruit ifAbsent: []" and we can
manipulate our namespaces and classes within them etc. IMHO the obvious
Smalltalk way - I presume Michael's solution in this respect is similar.

BUT... Andreas advised me *strongly* to let my Namespace instances
delegate to Smalltalk (the SystemDictionary) because otherwise tons of
code will break. So my Namespace instances behave like Dictionary but
actually don't hold anything at all! The class is *still held in
Smalltalk* just like before:

        (Smalltalk at: #Fruit::Orange) == Fruit::Orange

At this point people may be confused but it all boils down to this usage
pattern:

        - If you want to have a class Apple in your own namespace "Fruit", just
name it "Fruit::Apple"! It is that simple.
        - If you want to move it, just rename it! The Namespace instances I
describe are automatically created and maintained.
        - If you want to use it, just type "Fruit::Apple" (because hey, that is
the name of the class!) but of course, you don't want to type all that so
fine, just type "Apple" and it will automatically work! Different things
will happen then:
                - If there is no other Apple in your image it will just work. Apple. No
prefix needed. This covers 98% I guess.
                - If there are multiple Apple, Squeak will ask you which one you mean
(nice popup menu) and autoexpand it in place!
                - If there are multiple Apple BUT one of them is in your LOCAL namespace
(=the namespace of the class you are editing) then it will work just
fine with the short form, the local Apple is chosen instead of the
others. This covers perhaps 70% of those last 2%. :)

Let me repeat that: If you consider what I wrote above you will only write
(and read) fully qualified names (Fruits::Apple) if and only if there are
multiple Apples in your image (and I bet there aren't - 98% (?) of all
classes have most likely unique short names!) AND the method you are
editing is in a class in a namespace that does NOT have one of them (it is
not local).

Please let this sink in. This means we have NO IMPORTS and we still don't
need to write or read qualified names! How is this done?

Let's compare to Java. In java we avoid typing long names by typing the
paths once at the top of the file - the imports. Then we can use short
names in the rest of the file. This is classic. Anyone who knows Eclipse
and the alt-shift-o key combo knows that you ever hardly edit the imports
section because Eclipse *will do it for you* if you press that key combo!
So in Eclipse/Java you can emulate my proposal by pressing alt-shift-o
every minute (perhaps add a background process that does it? :)) and only
type short names! Yep, same effect. The only difference is that instead of
encoding the qualified names by splitting out the tedious long paths into
an imports section - in my proposal we simple *don't*! We use qualified
long names ALL THE TIME in the source. You can do that in java too - but
it would look like hell and be awful to type.

The trick is to let the source use fully qualified names at ALL TIMES and
just hook into the source code pane rendering code and the source code
editing code and make sure the tools "render" short names and accept short
names when being typed. Aha! So the trick is in the tools. The actual
source code is JUST LIKE BEFORE. And that is why my proposal is so darn
backwards compatible.

And the simplicity of this is very powerful. Every class reference is
fully qualified. If you add ten Apples in your image the old references
will still refer perfectly to the Apple they intended (Stephane's use
case), but suddenly they will *render* fully qualified since you otherwise
would not know which one they refer to. And if you remove 9 Apples the
references still around will suddenly render *short* again.

Another example, if you move a class from one namespace to another - that
is equal to a class rename operation - and Squeak already handles renames
rather gracefully - by offering all methods it is referenced to that you
can change them. Or using RB it can fix the references for you - I haven't
tested this but I bet this works PERFECTLY FINE with my proposal!

I hope my ramblings here have shown that my proposal is indeed VERY
SIMPLE, has NO IMPORTS, still avoids typing and reading of long names,
still are REAL namespaces (you can make an Apple and so can I) and is very
backwards compatible (hey, even old fileout formats should work just fine
and Monticello and all our other tools).

But what did I mean with "Smalltalk feel"? I meant that in Smalltalk we
don't have "modes". We can type a snippet of code anywhere and just run it
- the only thing that is context sensitive is "self" so to speak. But if
we start messing with java-ish conventional namespaces with imports we
suddenly have lost that "loving feeling" - we will have lots of "modes".
The snippet will bind and behave very differently based on where I run it.
Which class? What imports does it have? What does OrderedCollection
actually bind to? And how does a Workspace work? And what imports does the
debugger have and the inspectors and all other text panes? Please consider
this.

regards, Göran

Hi,

To keep it short, I've been heading down the same path on my own. So I should check out your package and see where you are, and maybe same myself some time. :)  Wonder if it'll break in 3.10.  Thanks for your write-up.

Jason

How would enhanced prefixes work to load several versions of the same classes ?

For Fruit::Orange and Color::Orange, we have the problem that the
English word is overloaded but the program entities could perfectly be
named OrangeFruit and OrangeColor. Your proposition makes it more
practical to invent and work with unique names indeed, but if I
understand correctly, your proposal moves the problem of clashes in
class names to clashes in prefixes.

For me, name spaces are about differentiating classes that can only
have the same name, because they actually are the same concept, only
in a different shape.

E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a
single image, I'm still stuck because they will both use Seaside:: or
WA:: as a prefix. I would need to change the prefix on the fly while
filing the code in (or loading it from MC) and, symmetrically, to
rename the client classes to use one prefix or the other.



--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

Hi!

> How would enhanced prefixes work to load several versions of the same
> classes ?
>
> For Fruit::Orange and Color::Orange, we have the problem that the
> English word is overloaded but the program entities could perfectly be
> named OrangeFruit and OrangeColor.

Sure, if we are AWARE of both we can avoid the clash - but typically we
aren't aware of both and get into trouble trying to load a class library
or whatever into an image in which we already have an Orange.

> Your proposition makes it more
> practical to invent and work with unique names indeed, but if I
> understand correctly, your proposal moves the problem of clashes in
> class names to clashes in prefixes.

Well, the "moves" is a bit harsh - AFAIK most other schemes do in fact
have names on their spaces and yes, you can end up with clashes in
namespace names too. But that is either more unlikely, solvable with
registries OR even better - solvable by remapping, see below.

> For me, name spaces are about differentiating classes that can only
> have the same name, because they actually are the same concept, only
> in a different shape.
>
> E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a
> single image, I'm still stuck because they will both use Seaside:: or
> WA:: as a prefix. I would need to change the prefix on the fly while
> filing the code in (or loading it from MC) and, symmetrically, to
> rename the client classes to use one prefix or the other.

Yes and no. :) Yes, you would need (or let us say "be able to"!) change
the prefix "while loading" to something else. And no, I don't think you
need to fall back on editing and recompiling referencing methods (if that
is what you meant by "rename the client classes").

I thought about having some kind of "map" that you can use, like:

WA mapTo: #WA26

...so that references to WA:: from that point on (when compiled) actually
are looked up in WA26::.

Or... you can do it like this too:

- Install Seaside 2.6 (into WA::)
- Install/compile all code that should be using 2.6.
- Rename the WA:: namespace:
       WA rename: #WA26.    (I was actually coding up #rename: today)
- Install Seaside 2.8 (into WA:: which now is free)
- Install/compile all code that should be using 2.8.

If I am not too rusty this can be done without recompiling anything
because the existing bindings can be "rebound in place" so to speak when
we rename the WA:: to WA26:: (reusing the same Association instances).

I haven't played around with such "remappings" yet but don't see any big
hurdles in making stuff like this work.

Btw, isn't it nice to be able to talk about WA:: (the syntax makes it
apparent that I mean "the namespace called WA")? Another nice effect of
using ::. Had I written WA. you would instead wonder why I started this
sentence with a lower case letter and you would not have understood I was
trying to refer to a namespace. :)

Anyway, IMHO the explicit prefixes combined with reified Namespace
instances (with some good protocol/code added) should make these things
clearly doable and understandable.

regards, Göran

Hi Jason!

> Hi,
>
> To keep it short, I've been heading down the same path on my own. So I
> should check out your package and see where you are, and maybe same myself
> some time. :)  Wonder if it'll break in 3.10.  Thanks for your write-up.
>
> Jason

I started this code in 2004 actually. The issue of namespaces pop up
regularly here in Squeak-dev and I try to explain it and push it and tweak
it a bit every time the subject comes up.

I would gladly see some help with punding on it and fixing some
outstanding issues etc. If you are interested (or anyone else for that
matter) - email me and/or pop up on IRC (irc.freenode.net, #squeak - I am
gokr or gok1).

I am going to OOPSLA late october and it would be neat to give it a push
until then. My other "labor of love" right now is DeltaStreams, which is a
tad related.

regards, Göran

Just 5 cents.

I don't know, really a reasons why we should keep with obsolete
doctrine in having global dictionary? Its a barrier in collaborative
environment which we should remove (and the sooner - the better),
because if we don't do anything and keep things intact, while squeak
code base will grow, soon there will be 5% instead of 1% in name
conflicts and will grow more and more.
In closed, self sufficient community there no need to have any support
in namespaces.
But i hope everyone here wants to see a squeak is a number one
smalltalk in the world, or we don't?

Giving a simple way to use global names in smalltalk was done for
convenience of developer. But now, we get to point that each conscious
developer, each time he needs to create new class should think twice
what name to give to it, because convenience to him here and now, can
turn into inconvenience for others later.
And, obviously, in such situation its more convenient for ALL to use
namespaces :)

A names locally bound to some Namespace don't change code drastically,
and code can stay backward compatible (unless you play with well known
names, like #Array or #Collection).

Most often uses of global names is references to well known kernel
classes like #OrderedCollection, #Array, e.t.c. If you take any random
class from any other package, you'll find that number of references to
it barely beyond 3.

So, i think that converting any userland(i.e. non-core) code to use
with namespaces is a task for couple of minutes, since before
conversion we had each unique name = unique class.

There are some problems when moving to namespaces like usage of
'Smalltalk at:/at:put:' code. But using reflective hammer we can
easily get around it:
- get caller context, get its method, get method's class, get class
namespace - do name lookup.
So, if we really want it, we can do it in backward compatible way.


On 19/09/2007, Göran Krampe <[hidden email]> wrote:
--
Best regards,
Igor Stasenko AKA sig.

I'd rather take the working system that Goran has and allow Gulik to
keep working on his.

Then we can debate the merits of switching to a different (completed) system.

On 9/19/07, Igor Stasenko <[hidden email]> wrote:

>
> I'd rather take the working system that Goran has and allow
> Gulik to keep working on his.

+1 on Goran's proposal!

Ramon Leon
http://onsmalltalk.com

This would mean that file-outs and Monticello packages would contain "::", am I correct? In this case, we can't go back because all source past that point can't be loaded by a non-Göran image.

Gulik.

>
> This would mean that file-outs and Monticello packages would
> contain "::", am I correct? In this case, we can't go back
> because all source past that point can't be loaded by a
> non-Göran image.
>
> Gulik.

It wouldn't be a Goran image, it'd be a standard squeak image, since the
whole point would be to include that fix in the base image to allow us to at
least take one tiny step in the direction of a solution that formalizes what
we're *already doing with class prefixes*.  Why?  Because no one will accept
any other solution, look in the archives, this battles has been fought many
times.  

Any "real" namespaces solution will eventually be rejected because it's not
a small change and a vocal part of the community doesn't want it, just wait,
you'll see.

Ramon Leon
http://onsmalltalk.com

My thoughts on your proposal, which I'm trying to keep technical rather than judgemental:

* It's a one-way street to adopt your proposal. I assume that file-outs and changesets will have all names contain "::". This means that any non-namespaced image can't use these file-outs, changesets etc.

* I assume that operations you perform on your namespaces such as renaming them will involve the tools modifying the source code for every method that uses that namespace? This isn't exactly elegant.

* I also assume that to resolve conflicts of the namespace names themselves, the tools need to give the namespace a completely new name (which changes the source code as it's filed in), and to do this you'd need input from the user?

* If non-namespaced code is loaded into the image, the user will need to manually resolve all ambiguous names, of which there will be more of because developers don't need to use class name prefixes any more.

* Your proposal still involves the use of a global dictionary containing all global variables and classes. In computer science we learn that the use of global variables should be minimised, and your proposal certainly doesn't help us in this regard.

* Your proposal doesn't completely solve naming collisions but instead reduce the likelihood of a collision happening. Collisions can still happen, and we still need to collaborate among ourselves to make sure two people don't use the same namespace.

In effect, what you're presenting as a namespaces implementation for Squeak is a way to hide class name prefixes from the developer, with a well-defined prefix format. It doesn't provide code with a particular context to resolve names in, but rather asks the user on a name-by-name basis to resolve ambiguity.

I'm not against your proposal, and it doesn't make the situation any worse than the current situation except for the filing out issue.

So +0 from me :-). I'd just like to ask you to put an easily-findable comment in the core parts of Squeak you change so that it is possible to remove it.

Gulik.

I'm aware of this. I think it's a shame because almost every other programming language supports encapsulated namespaces. Even C does to some extent - if you don't #include code, you can't use it.

I plan to keep my namespaces packages available and maintained on the PackageUniverse so it's there if people want to use it. It also happily co-exists in an image next to the SystemDictionary, so no great sacrifices are made to use it. The main issue is that I gave up trying to get Monticello to save Namespaced code[1], so you need to use my own proprietary packaging format.

Gulik.

[1] http://people.squeakfoundation.org/person/mikevdg/#6

Yes, I suggested this very idea in another of our epic Namespace
discussions three years ago.

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-April/076859.html

Glad to see the idea reconsidered once again!

Hey Göran, if we can dynamically rename, then do we need ANY namespace
solution at all then?

 - Chris

On 9/19/07, Damien Pollet <[hidden email]> wrote:

> E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a
> single image, I'm still stuck because they will both use Seaside:: or
> WA:: as a prefix. I would need to change the prefix on the fly while
> filing the code in (or loading it from MC) and, symmetrically, to
> rename the client classes to use one prefix or the other.

Recall also that method extensions are part of packages too and
currently suffer from potential name-collisions just like classes.
Unfortunately this is a much harder problem to solve, and reason why I
would never try to load two versions of the same framework into the
same image; i.e., because different implementations of the same method
extension may collide.

Hi,

> On 9/20/07, Ramon Leon <[hidden email]> wrote:
>
> > Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community doesn't want it,
> > just wait, you'll see.

This is a Good Thing. After all, how many poeple are ever going to write Traits ?

All the critics are saying is that the solutions, as presented, are flawed.

--
This is not an automatic signature: I actually type this into every message.

Hi all!

Indeed! Hehe, so yes, if the package in question has loose methods and any
of those differ between the two versions - then you are in trouble. Unless
we also start introducing "selector namespaces" (or whatever that thing
was called - the one that picks different implementations based on sender
- I think Stephen Pair toyed with that a while ago) - BUT... I just see
100% confusion rearing its ugly head.

regards, Göran

Hi all!

Yes, very well put. And also, check:
   http://swiki.krampe.se/gohu/35

...where I describe the minimal fix - module testing extensively, but as
you can see it is TINY. So if you happen to be sitting with an old Squeak
image and want to load new code using ::-names, just smack that changeset
in and go.


>  Why?  Because no one will
> accept
> any other solution, look in the archives, this battles has been fought
> many
> times.

Again, very well put.

> Any "real" namespaces solution will eventually be rejected because it's
> not
> a small change and a vocal part of the community doesn't want it, just
> wait,
> you'll see.

And also - all people rejecting any "real" solution (although I tend to
argue with that choice of word) - are not entirely wrong either.

I mean, we aren't really *suffering* here. :) It just happens to be a
"nagging itch" that we - as developers - like to approach somehow.

Also, note that given my proposal you CAN actually "tack on" additional
mechanisms like for example imports (for context dependent resolving). I
just tend to think they aren't really needed.

regards, Göran

By *real* I mean other overly complicated hierarchtical package managing,
code securing, auto class rename on importing, whiz-bang solutions that 99%
of us don't really need (obviously since we don't have that now).  I just
want the damned browser to hide the prefixes (aka manual namespaces) like it
formats the code, a simple aesthetic preference.  Nice, simple, keeps
Smalltalk as is, one global namespace, no imports, no ambiguity, just a
smarter view and a change small enough, with so little object to, that it
might actually happen within my lifetime.  As it stands, it's by far the
most pragmatic solution on the table.

Ramon Leon
http://onsmalltalk.com

Hi!

Highly annoying - I had written a long reply and then it went poof into
bit heaven. Ok, one more go:

[SNIP]
It is a tiny changeset (4 modified methods and one added in Parser/Scanner):

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

AFAIK that would be enough. Needs testing of course.

> * I assume that operations you perform on your namespaces such as renaming
> them will involve the tools modifying the source code for every method
> that
> uses that namespace? This isn't exactly elegant.

No, you can manipulate bindings too. This would simple change the
reference without touching source or recompiling. Kinda sneaky, but can be
done - I am toying with that now.

And of course if we all move to dynamic lookup (using whatever syntax)
then the problem is easy.
But I think we should allow both static and dynamic references.

> * I also assume that to resolve conflicts of the namespace names
> themselves,
> the tools need to give the namespace a completely new name (which changes
> the source code as it's filed in), and to do this you'd need input from
> the
> user?

Yes, but I have a hard time seeing a solution to this without a registry.
One may argue that the risk of collision would be less in an hierarchical
solution, but I tend to think that it is a small price to pay for the
greater simplicity.

Regarding changing source code - I think it opens up a can of worms
related to SCM and we should not go there.

BUT... (interesting trick coming up, helmet on!) one could argue that
since we are *already* "rendering" references we could be even smarter and
render remapped references differently:

Fruit::Apple (if in fact remapped to NewFruit::) could render as:

NewFruit(Fruit)::Apple

...or something. This is just "thought provocation" from me - not a real
proposal :).

> * If non-namespaced code is loaded into the image, the user will need to
> manually resolve all ambiguous names, of which there will be more of
> because
> developers don't need to use class name prefixes any more.

No, this one is false.

Non namespaced code referencing Apple will resolve to Smalltalk at: #Apple
- nothing else. So it would never "accidentally" collide with Fruit::Apple
because we ALWAYS store the fully qualified name in the source. So
Fruit::Apple is "Smalltalk at: #Fruit::Apple", and Apple is "Smalltalk at:
#Apple" - two different class names simply.

Or perhaps you mean when coding *later*? If you have Fruit::Apple and
Electronics::Apple and Apple in the image - and type "Apple" - yes, it
will ask which one you want. Unless coding in Fruit:: or Electronics::,
then it would autoresolve to the local Apple.

Hmmm, trying to recall if I auto resolve to a "short global" if there IS
such a global (and no local Apple) - but no, I don't think it does. BUT...
this is all just *tool policy* - just set a preference to favor globals -
and it will not ask. :)

Let me repeat that: How your typed characters get resolved is a tool issue
and can/should be controlled with Preferences.

> * Your proposal still involves the use of a global dictionary containing
> all
> global variables and classes. In computer science we learn that the use of
> global variables should be minimised, and your proposal certainly doesn't
> help us in this regard.

I disagree. I think this is just an implementation detail. If you can
improve it by making Namespace instances hold the Assocations instead of
using the trick I am using - then by all means - go ahead! It would be
cleaner implementation wise. But Andreas Raab strongly advised me to not
take on that "world of hurt" and I believed him.

The end result is the same though.

> * Your proposal doesn't completely solve naming collisions but instead
> reduce the likelihood of a collision happening. Collisions can still
> happen,
> and we still need to collaborate among ourselves to make sure two people
> don't use the same namespace.

Ehm, no, I would not put it that way. Two people can *use* the same
namespace - no problem. As long as they actually COLLABORATE and don't
*both* create Fruit::Apple! But this is obvious to me - a namespace can be
shared, they typically are - they just typically aren't shared with the
whole Planet. Sometimes they are only for one developer, sometimes for a
whole bunch.

But I guess you meant make sure two people accidentally don't pick the
same namespace *name*, right? Sure. But again, we are already there -
prefixes EXIST TODAY. We live with it, we have a registry. And if the shit
happens - we make sure there are ways around it. This would be quite rare,
I don't see it as a problem. And it should be sanitized, we don't WANT
multiple namespaces with the same name.

Also... you are saying "collisions can still happen" and YES, I agree. And
there is nothing wrong with that - in fact, I think it is an important
social mechanism! "Oops, you have also coded up something called
SocketStream? Interesting. I bet we should talk and merge or perhaps nuke
one of them etc."

This is GOOD. This is what I have been trying to describe as an
"optimistic approach" - anticipate and embrace collisions and deal with
them when they happen. Instead of letting each developer sit in a sand
castle and create tons of Date classes totally unaware that there are in
fact others out there.

> In effect, what you're presenting as a namespaces implementation for
> Squeak
> is a way to hide class name prefixes from the developer, with a
> well-defined
> prefix format. It doesn't provide code with a particular context to
> resolve
> names in, but rather asks the user on a name-by-name basis to resolve
> ambiguity.

Not entirely true either. It does have some "smarts" when it comes to
resolving - and as I have described, that can be experimented with at
will. Today it already auto resolves local Apples - if there is one.

And the way you say "as a namespace implementation" - you are trying to
make it sound like a trivial, non-worthy solution and not REALLY
Namespaces. Then I humbly ask: What is a REAL Namespace solution? What am
I doing that is NOT REAL?

> I'm not against your proposal, and it doesn't make the situation any worse
> than the current situation except for the filing out issue.

Given what I wrote above regarding filing out - do you still think it is
an issue? And also - does any OTHER solution do it any better? I don't
think so.

> So +0 from me :-). I'd just like to ask you to put an easily-findable
> comment in the core parts of Squeak you change so that it is possible to
> remove it.
>
> Gulik.

If it EVER goes in, of course. And if we (I and Matthew) get DeltaStreams
fully working you can even revert it :). (btw, revert actually already
works)

regards, Göran

Hi Ramon!

My check is in the mail, is 100 enough? Ehm, oops, I just mailed this to
the list.... ;)

Let me just point out a few current issues that we need to fix:

- Currently I render class references by using a *full parse* of the
method and fixing up the global references. This is of course the REAL way
to do it and only touches REAL global references and not stuff in comments
or what not. But it punishes browsing code of course, it feels slower. I
haven't looked closely at it - perhaps I did something stupid, but I also
toyed with hooking into Shout which obviously also is parsing code and
does it fast!

- Some tools are not caught by my low level hook, like method versions
browser for example. Need to catch.

- I have a vague recollection of filing out not properly working, I
probably shot myself in the foot somehow.

So... it is definitely not yet perfectly ready to go in - but with a bit
of work I think it would easily be.

regards, Göran