Hi Göran,

On Wed, Jun 27, 2012 at 1:35 AM, Göran Krampe <goran at krampe.se> wrote:


> 1. AFAICT this will (in contrary to my solution) remove the "modelessness"
> we have today. Or in other words, a code snippet will behave differently
> depending on which environment you are in. One can argue that this also
> holds true today (class variables shadowing globals for example) but still.
> It reminds me of VA for Java where you had to tell the "Workspace" in which
> class it was being run (in order to get all the imports right). I am not
> sure I like where this is leading. NOTE: My proposal meant that all class
> refs were actually in full, never short. They just "rendered" short when it
> was reasonable.
>

Yes, you're quite right. It's the main difference between this proposal and
VW, GST, and Gemán's GSOC work. I think Gemstone might be the only similar
implementation, although I'm not  conversant with the subtleties of
Gemstone.

To me, this is a feature, not a bug. By giving up the notion of a single,
universal view of the system, we gain a degree of freedom that we didn't
have before. If we write code that doesn't rely on knowing where to find
the classes it depends on, we gain the ability to redefine those
dependencies without altering the code.


> 2. Reading code will force me to always be aware of which environments are
> imported into the package I am reading. Otherwise I will not know which
> class is referred to when I read "Manager". NOTE: My proposal would always
> expand names into full names if there were more than two in the image.
>

Also true. But you could say the same thing about dynamic dispatch:
you always have to be aware the class of the receiver, otherwise you
won't know what method will be executed. We mitigate message ambiguity
with dev tools (implementors, explain) and we can do the same with
class references.


> 3. And finally, this is AFAICT the same "pessimistic" approach that Java
> etc use - in other words, each developer/project will create his/her own
> little sandbox (=environment) and will start creating duplicate names for
> things (knowingly or unknowingly) and will never really "notice" this
> because this solution will never make it apparent that it has been done.
> NOTE: My proposal would lead to ambiguous names being rendered with full
> path and also asking the developer if he meant Color::Orange of
> Fruit::Orange whenever he tried to type just "Orange" - thus making him
> (and all others) aware of the slightly unfortunate name clash.
>

In practice we tend to do this already. We just pick a prefix and rely on
that to avoid name conflicts. And why not? We're long past the point where
we can have a single, unmangled namespace for all the classes that might
get loaded into a given image.

Thanks for the pushback, Göran. Insightful as always.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120627/7c502f29/attachment.htm