A little namespace "proposal"
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Tue Apr 13 23:27:31 UTC 2004
Hi Lex and all!
(taking a break from messing with SystemDictionary)
"Lex Spoon" <lex at cc.gatech.edu> wrote:
> I don't think you mean that the lookup context lasts only until the next
> file in, i.e. that literally you only change the default lookup context.
> That proposal does not accomplish making code readable by default. If
> I file in Tweak and then Traits, then I end up with the Traits lookup
> context and have to read fully qualified names in the Tweak code.
Not wanting to sound like a parrot :) but again - why would we end up
having to read fully qualified names? You may not be describing my
proposal anymore (not sure) but if you *are* then the only reason for a
fully qualified name to appear in the Tweak code would be if an object
was referenced in a Tweak method that:
Is not defined in the Tweak namespace *and* is defined in at least two
different namespaces in the image.
I would guess there are very, very few such objects (classes).
> It is nice that one person is considering this issue. IMHO, the issue
> is vital and we must work out a way to manage inter-image transfers of
> lookup contexts. Otherwise, we will create something that is a net
> minus to Squeak. Without transmission of lookup contexts, people will
> in many cases have to read code that peppered with things like
> "Tweak::Delay". I'd rather have name collisions than have to read fully
> qualified code like this.
Still can't understand this.
> Does anyone disagree that we need to have inter-image management of
> contexts before we have an acceptible proposal?
Eh, yes! :)
BUT... I don't think we need to call any votes or anything at this
Personally I wouldn't vote for a namespace solution (ANY solution) to
enter Squeak without first having been hammered on for quite a while. So
we need at least one proposal *with* an implementation to try out and
then sleep on it before even thinking of any decisions.
> I don't know why "import list" has become a bad word, but it seems like
> a direct and simple way to solve the above issue. Simply let authors
> specify what lookup contexts should be used with the code they write.
Hmmm, you are using the term "lookup context" here and I am not sure
what you mean anymore.
Is it a Namespace? Or an "Andreas context"?
In my current vocabulary a Namespace is a named Dictionary with symbols
as keys and objects as values. An "Andreas context" or what I
subsequently called LookupContext is an object that is used by Compiler
and Browser to both help resolving unqualified names when compiling
Smalltalk code and to help rendering code in a suitable fashion. My code
currently just has a class called LookupContext with a few class side
methods that I use from here and there. The whole point is that it is
"pluggable" so Andreas could use a different set of rules if he wanted.
> Putting these declarations in classes seems suboptimal but a fine way to
> get going. Eventually we can let the declarations be put at different
> levels of granularity varying from packages down to individual methods.
> Anyway, I am not attached to the per-class import lists. However, it is
> essential to have *some* solution to this problem, so let's not reject
> it without replacing it with something else.
Well, we are obviously in violen disagreement :) but I say "Let's not
reject or select *anything* until running code has been presented.".
I will at least be presenting my solution and then anyone will be free
to present his or her solution or criticise what I present.
More information about the Squeak-dev