Larry Wall wrote:
> Jon Lang wrote:
> : 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.
>
> Except that the idea of monkey patching is that you're overriding
> something for everyone, not just your own lexical scope.
...right.
> While taking a shower I refined the design somewhat in my head,
> thinking about the ambiguities in package names when you're redefining.
> By my previous message, it's not clear whether the intent of
>
> multi package Foo::Bar {...}
>
> is to overload an existing package Foo::Bar in some namespace that
> we search for packages, or to be the prototype of a new Foo::Bar
> in the current package. In the former case, we should complain if
> an existing name is not found, but in the latter case we shouldn't.
> So those cases must be differentiated.
>
> Which I think means that multi package always modifies an existing
> package, period. To establish a new multi package you must use
> proto or some equivalent. So our previous example becomes either:
>
> proto package A {
> class Foo {...}
> }
>
> multi package A {
> class Bar {...}
> }
>
> or
>
> proto package A {...}
>
> multi package A {
> class Foo {...}
> }
>
> multi package A {
> class Bar {...}
> }
>
> Then we'd say that if you want to retro-proto-ize an existing class you
> must do it with something like:
>
> proto class Int is MONKEY_PATCHING(CORE::Int) {...}
> multi class Int {
> method Str () { self.fmt("%g") }
> }
>
> or some such monkey business.
By "re-proto-ize", I'm assuming that you mean "open an existing class
up to modification". With that in mind, I'd recommend keeping
something to the effect of "is instead" around, with the caveat that
it can only be used in conjunction with the multi keyword. So if I
wanted to redefine package Foo from scratch, I'd say something like:
proto package Foo { ... }
multi package Foo is instead { ... }
But:
package Foo is instead { ... }
would result in an error.
--
Jonathan "Dataweaver" Lang
