[squeak-dev] Re: Future of Squeak, and outsider's view

Juan Vuletich juan at jvuletich.org
Wed Jul 1 13:08:47 UTC 2009


Eliot Miranda wrote:
>
> On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <andreas.raab at gmx.de 
> <mailto:andreas.raab at gmx.de>> wrote:
>
>     ...
>     I really fail to see how it would make any difference whatsoever
>     if extension methods are in multiple packages or not. In either
>     case you are *completely* screwed if you have multiple packages
>     trying to extend the same method. Seriously, has there ever been a
>     situation where that actually works? (my personal preference is
>     actually that MC should blow up straight into your face if you try
>     to change a method that's in an extension category already, but
>     that's just me - I generally avoid extensions like the plague)
>
>
> I don't avoid extensions, and personally feel extensions are a core 
> part of building frameworks.  If objects are to interact they must 
> provide protocol to support that interaction.  In adding a new 
> framework to an existing system this means extending existing objects 
> so that they can interact with the new framework.  Yes, one can do 
> this badly, but there are lots of examples where this makes sense.
>
> As far as patching, we've had this conversation before.  I agree that 
> a well-designed system will provide extension mechanisms that make 
> patching unnecessary.

And later...

>
> Gilad is virulently against monkey-patching and so there is no support 
> for extensions in Newspeak modules...

Extension methods are useful, but can be dangerous. Problems will arise 
if a module modifies the behavior that is expected by the base system or 
by other modules that do not include us as a prerequisite.

Things a module should not be able to do to existing classes (defined in 
the base system or in other modules)
- patching: modify existing methods, including any extensions done by 
other modules
- add new methods that redefine inherited behavior (I mean, a method not 
already implemented but inherited)
- delete any method

Things a module should be able to do:
- extend existing classes with new methods that do not affect the base 
system or any other module that does not include us as a prerequisite

An easy way to ensure this is to require each module to define a prefix 
for its extension methods. The system must ensure that the prefixes are 
distinct for all modules, and that a prefix can be used only by its 
owning module to define new methods. The base system can not use any of 
those prefixes. A module can call a prefixed method only if it owns it, 
or it belongs to some other module that was declared as a prerequisite.

It is sort of cheap namespaces for methods (not for classes).

What do you think?

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list