On Thu, 06 Mar 2003 15:31, Brent Dax wrote: > Sam Vilain: > # > We musn't dictate style. > # > # No, but we should emanate good style. And I consider opening > # two class' > # namespaces into the same stash to be very bad style. > > We *must* support MI, delegation and interfaces in Parrot. Interfaces > can probably be implemented in terms of MI and/or delegation, so why not > do so?
I'm not disagreeing with you. But I think it would be good to specify exactly which methods you're inheriting via `is X', rather than all-or-nothing. This would allow for the concept of modules exporting Interfaces without the danger of collisions. But then, I guess so would simply mandating that classes export their interfaces cleanly, in chunks that are unlikely to collide. > # attributes. But - if > # the child class accesses an attribute which is defined in > # both classes, > # which does it get? > Neither. Attributes are private to the class that created them. A > subclass can't (well, shouldn't) access a superclass's attributes. Good. > Alternatively, the approach taken with MI namespace clashes in Perl 5 is > to let the programmer arrange the inheritance tree as he sees fit, and > to let him explicitly delegate when there's no single arrangement that > works. That's a lot more *useful* than a hard error. I can see a > warning that can be deactivated, but not a fatal error. You are right - but this is a different condition. There is no error in this case because there is no ambiguity as to which method to call. > class A { > method X { ... } > } > class B { > method X { ... } > } > class C is A is B { > ... > } > Making that a fatal error looks great on paper, but what if B::X was > added in the latest version of B.pm? Do you really want a *fatal* error > to appear on machines that upgrade B, but not those that don't? Do you > have any idea what a nightmare that would be for module writers? Isn't it more of a nightmare if this is silently accepted? > A warning to the effect of "Methods A::X and B::X conflict in mutual > subclass C", deactivatable with both 'no warnings <<oo>>' (or something) > and 'method X is from(A)', would please me much more. The manpage can > strongly encourage use of 'is from' when there's MI afoot. > But we're in language territory again. Parrot has to deal with this > issue in a flexible way, so always emitting a fatal error is simply not > an option. It sounds like you already have a plan - I didn't realise about `is from'. I'll shut up on this subject now :-). -- Sam Vilain, [EMAIL PROTECTED] There is more to life than increasing its speed -- Mahatma Gandhi