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