On Wed, Jul 1, 2009 at 9: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?
>
> Cheers,
> Juan Vuletich
>
>
In the absence of a modular system like Newspeak, this is probably the best
proposal.  It's probably even better than real selector namespaces, since I
think a modular system like Newspeak makes even that irrelevant.  I once
implemented real selector namespaces, modifying the compiler, updating the
browsers (you could see multiple methods of the same name in the browser
with the namespace to which each was affiliated in parens), etc.  It all
worked and was even almost comprehensible, but I still was left with an icky
feeling about it and abandoned the experiment.  I still think a modular
system makes this problem go away and short of that, your proposal is
probably the most practical.

- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090701/f3cefb9c/attachment.htm