Eliot Miranda wrote:
On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <andreas.raab@gmx.de mailto: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