Nicholas Clark wrote:
On Sat, Mar 10, 2007 at 04:51:28PM +0000, Jonathan Worthington wrote:
Different languages may have a different MRO. Python since 2.3 and Perl
6 by default use C3. Perl 5 used something else. Therefore, we need
uses
Hope that this makes some kinda sense - feedback would be *very* welcome!
Pedant point, I know, but any suggestion that Perl 5 is "special biologist
word for stable" seems to raise some hackles with the
over-sensitive-but-less-than-sensitive-about-it.
Argh, dammit. That was likely a typo or I meant "chose to use at the
time it was designed", but count it as what you want. I know full well
Perl 5 isn't dead. At least, I hope it's not, because I use it all the
time in my day job and expect to be doing so for a long time yet. :-)
And no, it's not pedant at all - I'm well aware of the issue you mention
and really don't want to be seen in the "Perl 5 is dead" camp. Thanks
for giving me a chance to clear that up.
Brandon Black has been working on making (IIRC) pluggable MRO for Perl 5 - you might want to talk
to him. We've not been able to give him much helpful feedback on the implementation of that,
because all the Perl 5 MRO code predates "change 1" - the import of 5.003 to perforce in
1997. I suspect it goes back to 5.000. As part of "we", I've really not thought about the
implications of this sort of thing.
Thanks for the lead.
Does it actually work having different classes in the same hierarchy
declaring their own MRO? For example, if A-F declare themselves to be
leftmost depth first (or whatever the correct term is for Perl 5's order), but
G-I declare themselves to be C3, will it work?
A
/ \
B C
/ \ / \
D E F
\ / \ /
G H
\ /
I
Specifically because I thought that with C3, in
J
/ \
K L
\ /
M
the search order is M, K, L, J, whereas Perl 5 does M, K, J, L.
So if the top diamonds are ordered the Perl 5 way, they flatly contradict the
guarantee of C3.
It might be that I'm confused, misremembering or undercaffeinated.
It's a confusing problem, for sure. I've thought about it, but as of yet
have no good answers. I don't think forbidding having classes with
different MROs in a single hierarchy is the answer, because that loses a
lot of the inter-language stuff that we want.
One option is to say that a class cannot have a different MRO than its
parent class, so if it's a conflict we take the parent class's chosen
MRO. That makes classes you inherit from work. It may be confusing for
people subclassing them in another language, but on the other hand you
have explicitly stated that you are pulling in a class from another
language (since the language name is in the namespace), there's a clue
about what you should expect. Of course, once you get three languages
down the tree, you have no clue which one your MRO is coming from just
by glancing at the import line. Which means in general you don't know. Hmm.
I can't really think of any other options at the moment, or at least
anything that's even vaguely sane.
Thanks,
Jonathan
