Hi!

Just a few remarks and then hopefully I will post some code next time.
:)

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> Three things to add, that might have been overlooked.  (It's a big
> thread!)

No, its huge! :)

> #1.  You do not have to tweak the names in the code, if you tweak the
> lookup list in the class definition.  So instead of changing "Delay" to
> "Tweak::Delay", you can simply add "Tweak" no the namespace list for the
> class.

Subtle point coming up:

If you are just talking about a different "way" to store the information
- I agree, might be easier, need to think a bit more about that. But it
sounds like you are instead describing an "import" model per class (just
like in Java), and that is different than what I describe.

An import model per class (this is not at all what Andreas describes
AFAIK) makes resolution of names to behave differently "over time".
First, then the import list is empty and you type "Delay" and there are
Tweak::Delay and Kernel::Delay to choose you ask the user to choose and
then you would add "Tweak" as an import to your class.

If you then later type "Semaphore" and there are Tweak::Semaphore and
Kernel::Semaphore in the system - what happens? Well, if this is a "Java
style" import you are describing it will not ask this time - just
resolve to Tweak::Semaphore. So resolution behaves differently over time
*and* differently from class to class.

In my model it behaves the same over time and the same for all classes
as long as you are working in the same "Andreas context" (and you aren't
modifying the behaviour of the context).

Sidenote: Thanks for getting some more pieces to fall in - the above is
IMHO important aspects of an "imports per class or package"-model that I
dislike.

BUT... if you are indeed talking about just a different way of "storing"
the information in the source (not expanding the names in the actual
method source, but instead somehow maintain a list in the class
definition) then... well, not sure it would work.

Scenario:

1. There is only one Delay in the image, Kernel::Delay.

2. You edit class Foo::Bar and type "Delay". No need to ask the user,
Compiler adds "Kernel" to the "namespace list" of class Foo::Bar.

3. Tweak::Delay is created. No problem, the method with "Delay" in it in
Foo::Bar still resolves nicely to Kernel::Delay using the list.

4. You edit another method in class Foo::Bar and type "Delay". Compiler
asks you to choose which one you mean, note how this is not an
"import"-model I describe. The user picks Tweak::Delay this time. Ehum,
what to do?


> This feels a little better to me.  When I type a method with an
> unadorned "Delay", then I am explicitly being vague and I don't want the
> dev tools to undo that.  :)  I'd *like* to be able to swap out
> namespaces and end up with a class behaving differently, as in the
> Socket example mentioned earlier.

Yes, you are being vague - but the Compiler still needs to resolve it. I
don't want the dev tools to throw away information. :)

What I mean is that when the Compiler has resolved it (with or without
your help) - then at that point there is more information at hand. If we
don't save that information in the source somewhere I think we might end
up in trouble.

To me it feels instinctively better to save it than to throw it away. It
appears that it will be much easier to handle upcoming situations.

> But aside from the abstract argument, it's easier to implement in
> Squeak.  :)  It is easier to tweak a class definition than to modify
> text-based code.  (Code is not an object in Squeak.  :(  )

True, but it is quite easy to get the parse tree (MethodNode) and then
do source edits based on it. There are even remnants from 3.3modules in
the image that does exactly this, which I am basing my upcoming demo
code on.

> It's an option that can be kept in mind.
> 
> #2.  DON'T ASK QUESTIONS.  If the user types a name that is not
> successfully bound, and the tool finds just one instance where the name
> is used, then pick that instance and go with it.  Don't ask the user to
> explicitly say "yes" to choices that are obvious, just because once in a
> thousand times they may pick a different option.

This I agree with. I think my proposal for "standard Squeak tool
support" was along such lines - only ask if needed. But anyway, that can
be tweaked as we go, and even controlled by Preferences.

> #3.  There should be some mondo-large namespaces around such as Squeak
> which include all the normal stuff.  Having them around will limit the
> impact of people writing a class which conflicts with something in the
> main image; sure it will conflict, but innocent users will never know
> because the compiler will see the Squeak version first.

Above you used the word "namespace" for Foo as in Foo::Bar. Now you are
using it for the thing Andreas calls "context". Perhaps this means you
are advocating a different model, not sure.

But if you are talking about Andreas "contexts" then I wholeheartedly
agree. Though I am not sure we would want too many of these different
"contexts". And I will lobby hard for having one default as "Squeak
standard" to minimize confusion.

> In general the approach sounds great to me.  Start by making a class
> called Namespace and let's see where we can go with it.  :)

I will post some code later on in which I have an object I call
"Namespace" acting with the responsibilities of what Andreas calls
"context". That code is more or less just hacked to show the demo of
"rendering" and to not wreak havoc on my image :).

But AFAICT the model I/we are talking about would be quite simple to
implement for real.
 
> -Lex

regards, Göran