Squeak and Namespaces

Göran Krampe goran at krampe.se
Thu Nov 30 11:48:24 UTC 2006


Hi!

> brad fowlow wrote:
>> Given that, do the merits benefit allotting a syntax change (a valuable
>> commodity) that could begin to fork the world into ::-dependent and
>> ::-free code?
>> Or would it would be better to acknowledge that letter-prefixing is just
>> about as good, and free, and already there, and hold out for a stronger
>> solution without colonizing the code pool in the meantime?
>
> Bingo. That's precisely the concern I was voicing earlier.
>
> Cheers,
>    - Andreas

Well, I of course do not claim any Truth (TM) here but:

- Syntax change: Well, it is about allowing $: in class names. Sure, in
principal this is a syntactic change I guess. But we aren't talking about
anything more or less.

- Regarding changing Squeak from the compatibility view (not brought up
above): If we are *that* concerned then lots of other changes recently are
much more earth shattering (Traits, Pragmas etc).

- If you take an old Squeak you only need to modify 3-4 methods
approximately to get it to work with new ::-code. Do realize that many
other components and changes in Squeak like m18n etc are much more
disruptive regarding "forking the world of Squeak" when it comes to old
and new Squeak. And there are also lots of changes, even on the language
level, being done in other "forks" of Squeak like Croquet or Tweak. In
fact, it was Andreas that "triggered" this (my solution) way back when he
wanted modifications done to the Parser/Scanner to allow "scoped
variables". In fact, some of these modifications are already in Croquet
(if I am correct)!

- Regarding the benefits of my ::-solution, see my answer to Stephane.

- Also, we don't *have to* colonize the base code pool if we add this. As
I noted I think that the '' (empty) Namespace (=Smalltalk) should be used
for our current classes in the basic image.

- And finally, about "holding out for a stronger solution":
   - I really don't think my solution is "weak". It is different.
   - I really think it will be hard, hard work introducing an elaborate,
hierarchical, imports-based, alias-enabled model without destroying
much of the feel of Smalltalk. And TONS of people will argue against
it, since it will be such a radical change. Just my guess.

Btw, I have started that walkthrough here:

   http://swiki.krampe.se/gohu/35

...during that (last night) I discovered that the core does not work on
its own currently (the scopeVariable method needs to work in a more
simplistic way) - but it is approximately correct. :) I will fix that. The
idea is of course that the core changeset is all you actually *need* so if
you grab a Squeak 3.2 you file that in and tada - all new ::-code loads
and works fine. And you can even write such code in 3.2 etc.

regards, Göran

PS. It feels like history is repeating itself. Within a week I will
probably have given up on getting this accepted all over again and it will
be dormant for another few years. I guess it all depends on the current
board and on the upcoming release team leaders.




More information about the Squeak-dev mailing list