Sam Vilain:
# > Alternatively, the approach taken with MI namespace clashes
# in Perl 5
# > is to let the programmer arrange the inheritance tree as he
# sees fit,
#
# 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.
In Perl 5, if there's an A::X and a B::X, the module writer arranges the
inheritance tree to get the one he wants. That's what I'm talking
about. The defined semantics of Perl 5 inheritance resolve the
ambiguity, but it's the module writer's duty to see that they resolve it
*correctly*. :^)
# > 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?
Who said it would be silent? I mentioned emitting a warning below. The
module writer will fix the warning, and module users can disable the
warning easily until the new version is out.
# > 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.
#
# It sounds like you already have a plan - I didn't realise
# about `is from'.
# I'll shut up on this subject now :-).
Ugh...sorry, that was rabid speculation on my part. I should have made
that more clear. (I do that way too often...)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
