<br><br><div class="gmail_quote">On Wed, Jul 1, 2009 at 6:08 AM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a> <mailto:<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>>> wrote:<br>
<br>
...<div class="im"><br>
I really fail to see how it would make any difference whatsoever<br>
if extension methods are in multiple packages or not. In either<br>
case you are *completely* screwed if you have multiple packages<br>
trying to extend the same method. Seriously, has there ever been a<br>
situation where that actually works? (my personal preference is<br>
actually that MC should blow up straight into your face if you try<br>
to change a method that's in an extension category already, but<br>
that's just me - I generally avoid extensions like the plague)<br>
<br>
<br>
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.<br>
<br>
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.<br>
</div></blockquote>
<br>
And later...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Gilad is virulently against monkey-patching and so there is no support for extensions in Newspeak modules...<br>
</blockquote>
<br>
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.<br>
<br>
Things a module should not be able to do to existing classes (defined in the base system or in other modules)<br>
- patching: modify existing methods, including any extensions done by other modules<br>
- add new methods that redefine inherited behavior (I mean, a method not already implemented but inherited)<br>
- delete any method<br>
<br>
Things a module should be able to do:<br>
- 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<br>
<br>
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.<br>
<br>
It is sort of cheap namespaces for methods (not for classes).<br>
<br>
What do you think?<br>
</blockquote><div><br></div>Hi Juan,<div><br></div><div> 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.</div>
<div><br></div><div>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 :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Cheers,<br><font color="#888888">
Juan Vuletich<br>
<br>
</font></blockquote></div><br>