On Fri, Feb 13, 2009 at 10:46:42AM -0800, 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.
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.
Larry
