Larry Wall wrote:
> Jon Lang wrote:
> : Well, we _do_ have a mechanism in place for adding to an existing
> : class (e.g., "class Foo is also { ... }"), and classes are a special
> : case of modules; so I don't see why you shouldn't be able to do
> : likewise with modules and even packages.  That said, I'd be inclined
> : to suggest that if this is to be allowed at all, it should be done
> : using the same mechanism that's used for classes - that is, an "is
> : also" trait.
>
> These are actually package traits, not class traits, so your reasoning
> is backwards, with the result that your wish is already granted. :)

Darn it... :)

> However, it's possible we'll throw out "is also" and "is instead"
> in favor of "multi" and "only", so it'd be:
>
>    multi package A {
>        class Foo {...}
>    }
>
>    multi package A {
>        class Bar {...}
>    }
>
> to explicitly allow extended declarations.  Modifying a package:
>
>    package A {         # presumed "only"
>        class Foo {...}
>    }
>    ...
>    multi package A {
>        class Bar {...}
>    }
>
> would result in an error.  In that case, the pragma
>
>    use MONKEY_PATCHING;
>
> serves to suppress the redefinition error. It would also allow:
>
>    package A {         # presumed "only"
>        class Foo {...}
>    }
>    ...
>    only package A {
>        class Bar {...}
>    }
>
> to do what "is instead" now does.
>
> Apart from the parsimony of reusing an existing concept, the advantage
> of doing it with "multi/only" is that the parser knows the multiness
> at the point it sees the name, which is when it wants to stick A into
> the symbol table.  Whereas "is also" has to operate retroactively on
> the name.
>
> This also lets us mark a package as explicitly monkeyable by design,
> in which case there's no need for a MONKEY_PATCHING declaration.

And with package versioning, you may not need an "is instead"
equivalent: if you want to "redefine" a package, just create a newer
version of it in a tighter lexical scope than the original package was
in.  You can still access the original package if you need to, by
referring to its version information.

And that, I believe, would put the final nail in the coffin of the
MONKEY_PATCHING declaration; without that, you'd still need the
declaration for the purpose of allowing redefinitions.

-- 
Jonathan "Dataweaver" Lang

Reply via email to