[squeak-dev] class name collisions

Craig Latta craig at netjam.org
Fri Dec 19 18:26:48 UTC 2014


Hi all--

     At the last Squeak board meeting, we discussed approaches for
avoiding class name collisions, including Environments.

     I'm against both Environments and prefixes. We don't need aliases
in order to avoid using prefixes. We can transfer behavior directly as
compiled methods, letting us use whatever names we like in source code
because source code is not the medium of exchange.

     To properly compile a transferred method in a target system, you
want the target system to be compatible (e.g., classes defined with the
slots that the method expects). But if you have that compatibility, you
can just transfer the compiled method directly, without recompiling
source at all. So we should just transfer compiled methods directly,
allowing authors to use whatever class names they like in source code.
We can preserve the object identity of the class objects; the class
names are irrelevant.

     Name And Identity Are Distinct: this is the fundamental concept
behind Naiad, the module system I wrote. I think we should use it
instead of Environments. Please see [1] for development artifacts, and
create issues for things that are broken or missing.

     This is the beginning of my next push to provide Naiad as an
alternative to Environments (and, eventually, as an alternative to
Monticello/fileouts/Store/Envy/etc.).

     Are prefixes so bad? I think they're an unnecessary and ugly
kludge. And when a bunch of them build up, I find it quite annoying.
When I see a prefix, the system is just teasing me with the fact that
there is important further information I should know (author, features,
etc.), without providing a good place to store it and keep it updated,
or giving me a good way of finding it.

     I envision the method browser displaying a name which is used by
multiple loaded classes with some visual emphasis. Then I know that I
can hover the mouse over it (or whatever) and get a summary of info
about that particular class object from the history system (e.g., the
author, features, etc.). I think it would be less complex than using the
current method-versions tool is now.


     thanks,

-C

[1] https://github.com/ccrraaiigg/context

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)



More information about the Squeak-dev mailing list