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
