New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DFS does not respect superclasses’ MROs #11821
Comments
From @cpansprout#!perl # a @d::ISA = qw 'b c'; package d { use mro 'c3' } package subclass { @ISA = 'd'; } $\="\n"; __END__ The output shows that a c3 class fails the empty subclass test, because the subclass, which uses dfs by default, imposes that on its superclasses. I think this is a flawed model. It means that no existing module hierarchies can switch over to c3 without breaking subclasses. I think dfs mro linearisation needs to use the mro linearisations of its parents, instead of traversing all the superclasses itself. Likewise I think c3 needs to be modified. It may not follow the c3 algorithm any more, but right now it�s impossible to use the c3 mro in the example above if class �a� happens to have dfs diamond inheritance from its superclasses. (Maybe the c3 algorithm should treat any class that does not use c3 as a �black box�: it just takes the mro linearisation from that class and considers it a list of immediate superclasses.) Likewise, next::method should respect each class�s mro. Otherwise, the current mro system is more a curiosity than anything else. It�s not possible to use mro plugins to store the list of superclasses somewhere other than @ISA. Right now, to subclass a random class, one has to �use mro(); use mro mro::get_mro $super�. Easy things should be simple and vice versa. Flags: Site configuration information for perl 5.15.5: Configured by sprout at Sun Dec 18 11:26:14 PST 2011. Summary of my perl5 (revision 5 version 15 subversion 5) configuration: Locally applied patches: @INC for perl 5.15.5: Environment for perl 5.15.5: |
From @doyOn Sun, Dec 25, 2011 at 02:16:28PM -0800, Father Chrysostomos wrote:
I don't think the concept of a class hierarchy having multiple MROs even -doy |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgdoy is right, mixing MROs doesn't make much sense. The entire method -zefram |
Migrated from rt.perl.org#106998 (status was 'open')
Searchable as RT106998$
The text was updated successfully, but these errors were encountered: