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

Eliot Miranda eliot.miranda at gmail.com
Thu Jul 2 16:40:20 UTC 2009


On Wed, Jul 1, 2009 at 6:08 AM, Juan Vuletich <juan at jvuletich.org> wrote:

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

Hi Juan,
    basically my experience leads me to disagree that one can't patch.  I
think one needs to patch.  The difference is between the kind of package and
how deep the change it needs to make is.  if, like me, you're working on the
compiler you *absolutely need* to patch existing base classes to install a
new compiler unless the system was architected to have a new compiler in the
first place.  This is the tension.  When the system is well-enough
architected one can use pluggable schemes that have been provided to avoid
base patches.  But real systems don't have those facilities everywhere and
only have those facilities in places where system designers have the
foresight to provide them.  But to modify a system by loading packages to
get to a point where it is more pluggable you'll need to patch base classes.
 Chicken and egg.  So I prefer the approach that provides absolute power
(you can patch anything) and provides argumentation guidelines and examples
that help people avoid using that absolute power unless they absolutely have
to.

I think there's an analogy with become and thisContext.  These two features
are extremely powerful and can be horribly abused (along with MNU handlers
:) ).  But in practice they don't get horribly abused, except perhaps by
people experimenting and learning.  But think what the system would be like
*without* become and thisContext.  It would loose huge amounts of power.
 With power comes responsibility but without power there is impotence and
apathy :)


> Cheers,
> Juan Vuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090702/e9402e06/attachment.htm


More information about the Squeak-dev mailing list