On 3/2/07, Todd Blanchard <tblanchard at mac.com> wrote:

> It seems there have been some attempts at this in Squeak - islands?
> Squeak-E?  I haven't followed them.

Squeak-islands and Squeak-E haven't been worked on for ages. I have
plans to make a secure fork of Squeak using salvagable code from both,
but don't hold your breath :-).

> But this is easy given that Java freezes everything at compile time.
> No extensions to anything allowed post-compile (ok - post load).
> Unfortunately, the bar is higher in Smalltalk as we want to allow
> extension of anything.

I assume you mean being able to add methods to any class in the image
rather than just the classes in your own package?

> I don't think it would be conceptually hard to do something similar
> in Smalltalk if you were to have class lookup work similarly to
> method lookup but along namespace hierarchies.

I'm working on that.

Now... if I make a stable, usable, clean and largely
backwards-compatible solution, will people integrate it into Squeak?
It would be a very large, dare I say revolutionary change.

> The other thing that
> would make extension safe is a copy on write semantic with class
> wherein extensions to classes that are not local to your namespace
> result in a new class with the same name in your namespace being
> created that derives from the class in the parent namespace.  Thus,
> your mods are kept local to your context.  It does make class binding
> harder as class names have to be resolved dynamically in the methods
> that reference them.

That's harder.

How do you plan to make sure that instances of the original class have
their method lookup redefined automatically? Say for example that you
redefine a method in Object - how would you make sure that a String
literal in your code would have your redefined method in it's
superclass hierarchy?

Personally, I don't think it's ever necessary to redefine methods in
"System" objects such as Object, Collection or String. Other
programming languages manage fine without being able to do this.

The most common reason people do this is to check if an instance is of
a certain class (like Object>>isMorph or Object>>isMyStupidClass) -
people should use isKindOf:. If that is too slow then isKindOf: should
be made a primitive method.

Methods like String>>isURL don't belong in the String class! That
should be URL class>>isURL:. Object>>asMorph should be Morph
class>>fromObject:, and so forth.

Michael.