Hi Colin and all!

Note: I have apologized in another posting for my "tone" in my previous
post.

Colin Putney <cputney at wiresong.ca> wrote:
> Quoting goran.krampe at bluefish.se:
> 
> > And you are still only viewing "LookupContext" from Andreas POV namely
> > that it has some kind of import list in it. And I have expressly said
> > that my proposal for a default LookupContext object implementation meant
> > for "normal Squeak" has no such thing.
> >
> > You can of course say that my proposal sucks and that we surely *must*
> > have imports because all the other languages have them. But then say so
> > out loud and don't make it sound like my proposal has import lists -
> > because it has *none*. Not in namespaces, classes, packages nor in the
> > LookupContext. Ok?
> > 
> > And since it has no import lists then there is no point in storing them
> > either. :)
> 
> Let's say that your proposal is suboptimal.

:)

> The current situation is that there is exactly one context in which names are
> resolved. If we introduce namespaces, then there will be several such contexts
> in the image. So when we compile code, there must be some way of deciding what
> context will be used for lookups, no?

Well, we have messed up our terminology a bit here (context vs namespace
etc), but I agree in principal.

> Your proposal is essentially late-bound. The decision is made separately for
> each and every lookup. It assumes that most of the time there will not be more
> than one context in which a particular name could be resolved, and deals with
> such conflicts by asking the user to manually resolve the conflict. It also
> dynamically tweaks the display of source code to resolve ambiguities before
> it's presented to the user. This is my understanding of your proposal, of
> course, so if I've misunderstood, by all means correct me.

No, it sounds correct. Except you are using the word "context" and I
would have said "namespace".
Also - my current proposal regarding "default behaviour" is that it
doesn't ask if the name is defined in the namespace of the class itself
(even if there is another namespace with the given name).

> I prefer to have more consistency in my coding environment, even at the cost of
> some dynamicity. I agree with Andreas that code should be written and viewed in
> some specific context, and that temporary excursions into another context
> should be explicit. So consider what implied by the presence or absence of a
> namespace qualifier in the source code of some method. With your proposal, an
> unqualified name means that there is only one class of that name in the image,
> but a fully qualified name means there are more than one.

Well, there is also the situation where there are more than one but the
class resides in the same namespace as one of them - so it is assumed
the reader is aware of this and understands that it is the local binding
that is being referred to. Otherwise you are correct.

Again - different context (as in "Andreas context") implementations are
possible. In my code I have one separated out, but another
implementation could use different rules.

> With Andreas', an
> unqualified name means that the class belongs to the context I'm working in,
> while a qualified name is a flag that I'm temporarily reaching out into another
> context to do something unusual. That flag was put there by the programmer who
> wrote he code, and so conveys information about his intent at the time. Your
> proposal only gives me information about the current environment, which is
> available though other channels.

Well, given my correction above, my implementation (just like Andreas')
also renders "local" names unqualified even if there are other
namespaces with it. But his would render all "forreign" names fully
qualified which would make a LOT of code unreadable without import
lists. Which he has though. :)

> > Sounds like you are advocating an "import"-model where packages import
> > 1-n namespaces. I still wonder why people are so completely "hung up" on
> > import-models. I really do.
> 
> Nah, I'm not hung up on imports. They're just make a good way to construct a
> lookup context to associate with my code. They're explicit, as opposed to
> implicit. If you've got a better way of explicitly specifying a (potentially
> complex) lookup context let's hear it.

Well, my "better way" is to argue that we don't need to specify them. If
you let me use some different terminology for a second here my proposal
is like if all Namespaces exported all their names by default, instead
of the other way around.

So since they do - there is no need to import them - they are all
visible by default. BUT... this of course means that some names have
multiple values (same name is exported from multiple namespaces) and
that is OK up until you try to refer to it. Then you will need to
specify which one you mean.

This "export all by default" also means that we will all discover when
multiple packages actually define the same name. And that is IMHO good!
This is the "optimism" I am talking about - we are all sharing one
namespace when it all comes down to it - namely our own memory. I don't
want 10 different BufferStream because even if they are in different
spaces they pollute my *head*.

So I *want* that to create "a stir". It will not create actual
conflicts, but it will get noticed and hopefully resolved. And if it
can't be resolved by renaming some of them - it can be resolved by the
"inversed export" - the "shyness" mechanism thus preventing that name
from being exported.

But then to specify that name you will need to know it is there - it
will not appear in the popup-menu asking the developer to choose.

> > I just hope you are aware of the fact that I am coding too. :)
> 
> Yeah, but I don't like the direction you're going. ;)

Well, that is fair! :) We might want to share code nevertheless. I
intend to post later tonight what I have so far.

> > > Ok, that last bit about assigning a namespace to a package obviously isn't
> > > implemented yet, but the rest is. The nice thing about this scheme is that
> > the
> > > source code doesn't shift under your feet as you load different packages
> > with
> > > different namespaces, but the neither is it cluttered with fully qualified
> > > names.
> > 
> > Why are you saying "the nice thing about this scheme" as if these two
> > things are NOT true in my proposal?
> > I repeat again (and again if needed):
> > 
> > - No source is changing "under your feet" in my proposal. The source (as
> > kept in memory, as saved in changelog, as filed out etc) etcALWAYS has
> > the qualified names in it. ALWAYS. ALWAYS. Ok?
> 
> The source does change. What's in the change log is not what I typed in. What is
> filed out is not what I typed. If I load my code into a different image or load
> a package into my original image it might not look the same as it did when I
> typed it in. If I file in code that some one else wrote I might not see what
> they wrote.

I don't really see the harm here. We are only talking about prefixes
being shown or not.
And also - if people use pretty printing that is a much bigger
difference IMHO.

> The code does change, and it does so in unpredictable ways.

Unpredictable sounds like it would be random. It is very predictable I
think.
 
> > I would appreciate it if people at least tried to understand my proposal
> > before bashing it (slightly annoyed). And perhaps even look at the code
> > that demonstrates a fully working "rendering" that I describe.
> 
> I have tried to understand your proposal, and I have criticized it based on that
> understanding. If I misunderstood, by all means correct me. But don't assume
> that just because I disagree I must not understand. There *are* other points of
> view, you know, and some of them are even legitimate.

I know - and I did apologize in the other post. It just seemed to me
that you hadn't bothered to understand my proposal, given what you
wrote. My bad.

> For my part, I'm slightly annoyed by the straw man attack in your first
> paragraph above. I do not advocate imports because "we surely *must*
> have imports because all the other languages have them." To characterize my
> position (and that of Andreas) that way is misleading. 

Fine. It just seems like so many are so fixated with explicit importing
that different approaches aren't even considered. I can only say that
the explicit importing models (not "Andreas' context", that is a
different thing since he isn't doing it in the source but in the tools)
have great problems, a quick look at the Java world shows that IMHO.

Also - I would still like to hear about how the Workspace problem is
solved - or how the "oops, I changed a method and now other methods need
to be recompiled"-problem is handled. The last one seems to me like it
could trip up debugging pretty hard. What is I am editing method A in
the debugger and that causes the tools to change the importlist of the
class which in turn triggers a recompilation of method B which just
happens to be higher up in the call chain? Well, I don't know.

> Yes, I do think explicit definition of the lookup context is a good thing. But I
> don't insist that it be done through imports, and I certainly don't propose
> imports they way other language have done them.

Oh. Great. :)
Not sure what that means though but I am sure you will post code to show
me. :)
 
> Cheers,
> 
> Colin

Cheers, Göran

PS. And I really do apologize. :)