On Wed, Jul 1, 2009 at 9:08 AM, Juan Vuletich juan@jvuletich.org wrote:
Eliot Miranda wrote:
On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <andreas.raab@gmx.demailto: andreas.raab@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