On 10/26/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: > What about: > > class Foo is also { > method foo() { ... } > } > > Where the second foo() is no longer what the first foo() did.
Just overwrite the vtable. > Furthermore, let's say you have: > > class Bar isa Foo { > method floober() { ... } > } > > If they were roles, then role Bar could alias all the methods it > inherits from role Foo. In other words, it can cache all the method > lookups at compile-time. That's a substantial savings. If they're open > classes, the runtime has to throw out all the cached lookups the > moment any of the classes upstream are modified. This one is a little better. It is expensive to rejig all the cached methods, but that expense comes at the time when you reopen. If you never reopen, you never pay a penalty. > Plus, the argument is a straw man. Instead of: > > class Some::Class is also { > } > > you would do: > > class My::Version { > does Some::Class; > } > > Problem solved. Unless your module is the one creating the Some::Classes, or unless (as you point out above) there are existing subclasses of Some::Class, or unless some other thing that you didn't think of, which is the whole point of this discussion. There is no omniscient library writer; there is no omniscient language designer. :-) Luke