[squeak-dev] Re: Future of Squeak, and outsider's view
Juan Vuletich
juan at jvuletich.org
Wed Jul 1 13:08:47 UTC 2009
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
More information about the Squeak-dev
mailing list
|