Java's modules rock? (was Re: election details)

stephane ducasse stephane.ducasse at free.fr
Fri Mar 2 07:58:52 UTC 2007


I would be curious to read what you have done so far. Do you plan to  
send something to ESUG research track.
It would be cool.
Now how your extension solution compares with selectorNamespace and  
classboxes. Because the lookup of classbox
follow the import chain first then inheritance (this is may be too  
early to get my neurons working correclty)
And classboxes are hidden namespaces with import too, if you did not  
notice.

Stef


On 2 mars 07, at 02:31, Michael van der Gulik wrote:

> 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.
>
>




More information about the Squeak-dev mailing list