Namespaces (was: Re: [ANN]A plan for 3.8/4.0...
(insertdrumrollhere))
stéphane ducasse
ducasse at iam.unibe.ch
Sat Apr 3 09:28:50 UTC 2004
> As Andreas points out, the tough part about implementing namespaces
> (and Traits
> and Classboxes and Packages and every other experiment at the
> meta-level) is
> making the tools support it smoothly. Insert my shameless plug for
> OmniBrowser
> here. Making this sort of thing easier it what it's for.
>
> Also, I think Goran's point is well taken, and it suggests a deeper
> issue. I
> think we'd all agree that some way of handing naming conflicts will be
> necessary as we move more and more towards images built by loading
> independently maintained packages. However, if we want Squeak
> namespaces to be
> more than a checklist feature, we need to decide what their purpose
> is. The
> complexity they add to the system had better solve a real problem, and
> if we
> can identify the problem clearly, I think the desired semantics will
> be pretty
> clear as well.
>
> This sounds obvious, I know, but I'm not clear on the whys behind the
> implementations proposed so far. Stephane, you mentioned that
> Classboxes are
> meant to protect the system from broken packages. Is there more to
> that?
> Andreas, why did you add namespaces to Tweak? Avi, what do you want to
> accomplish with your proposal?
I think that you are asking the right questions:
- goal
- impact on the environment
The choice of andreas was how to support namespaces without impacting
the scope of the
user with unnecessary symbols and preserving as much as possible as the
current environment.
(I was driving late yesterday and I tried to understand what I wanted
to say in my idiot post). But the
price is that you have somehowe explicit namespace or scope access. So
as a user I may see that there are namespace and refer to symbol
outside the world. (for me doing that what was I called programmer
audience vs a scripter would not have to worry or have the possibility
to use the :: operator).
Our goal was not conflict resolution such as prefix, but how can we
control the scope of changes.
How a class extension can be controlled (a bit in similar way that
selector namespaces)? So a namespace is implied in classboxes but this
is not the main point. This is an implementation consequence. Our
idea/question is: what is the smallest mechanism that lets me believe
that the world is the one I see from my perspective (without explicit
context operator like in Us) and without explicit namespace references.
How can I make sure that if I change a method in another classbox this
modification will be only seen by me (note that this changes should be
seen
if I call another method that calls the modified methods, we called
that local rebinding).
The idea is that I can load code in a classbox and if the code redefine
OrderedCollection do:
the other classbox and the system should not break apart. It will when
I execute an expression in the classbox breaking the system.
Now this has some costs:
- we need another environment that is class box aware (what andreas
solution avoid
- we need another lookup (for local rebinding) but local rebinding is
not intrinsically
linked with classbox this was more a research experience to see how
far we can go
Alex modified the VM but now as a solution that does not require it.
He will provide
a version that does not have local rebinding so that people can play
with classboxes.
Our goal is not to have namespace in Squeak or even classboxes. We will
experiment with our
own languages and people can use it or not.
More information about the Squeak-dev
mailing list
|