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

Michael van der Gulik mikevdg at gmail.com
Tue Mar 13 00:47:54 UTC 2007


On 12 Mar 2007 23:53:15 +0100, Lex Spoon <lex at lexspoon.org> wrote:
>
>
>
> In practice, it has proven very valuable that Smalltalk modules are
> allowed to modify the system classes.  This is a dangerous thing to
> do, of course, but I would really hate to handicap the above fine
> packages just because of the *potential* for danger.  Instead, we
> should admit that inter-module conflicts exist, and deal with
> them head-on, as they happen....



You can never be sure that whatever object you're working with does in fact
have Object as a superclass. This is particularly relevant with my project
(DPON): I'm capturing message sends to objects to implement remote objects.

Also, it's a requirement in my remote code system that loading one module
using whatever mechanism physically CANNOT start causing strange symptoms in
other modules. . This is a basic security requirement. What I'll probably do
is prevent modifications to core classes like Object and String.

In my opinion, code not related to the functionality of a particular object
(such as any of the morphic methods on Object) should not be there. It
should be refactored so that it is in the classes relevant to what the code
is trying to do. For example, Object>>asXML should really be something like
XMLEncoder>>encodeObject:, where the implementation makes use of >>isKindOf:
or >>canUnderstand:. It's a bit more verbose, but prevents inter-module
conflicts and keeps your code where it is relevant.

Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070313/c8a24f30/attachment.htm


More information about the Squeak-dev mailing list