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
Possible mro bug/change between 5.8.8 and 5.10.0 #9746
Comments
From @nwc10Schwern mailed p5p in 490251F1.30507@pobox.com To quote: There's a problem with DBIx::Class::CDBICompat on 5.10.0. I was talking about I don't know much about mro or C3, but Matt thinks it might be a 5.10 |
From p5p@spam.wizbit.beI'm currently trying to create a small test case based on this bug (My very first guess however goes to MRO::Compat) |
p5p@spam.wizbit.be - Status changed from 'new' to 'open' |
From p5p@spam.wizbit.be
Trimmed down version attached. Running it: 5.008008 5.010000 5.8.8 calls RT66096::Two while 5.10.0 calls RT66096::One... mk_group_accessors is called via RT66096::Test->mk_group_accessors @RT6609::A2::ISA = RT66096 @RT66096::A1::ISA = RT6096::One @RT6609::A2::ISA is updated to RT66096::A1, RT66096::Two, RT66096 @RT66096::A1::ISA is set to RT6096::One => so @RT6609::A3::ISA really But in perl-5.8.8 the calls goes to RT66096::Two and in perl-5.10.0 to I believe the behaviour in perl-5.10.0 is 'correct' and the behaviour Best regards, Bram |
From [Unknown Contact. See original ticket]
Trimmed down version attached. Running it: 5.008008 5.010000 5.8.8 calls RT66096::Two while 5.10.0 calls RT66096::One... mk_group_accessors is called via RT66096::Test->mk_group_accessors @RT6609::A2::ISA = RT66096 @RT66096::A1::ISA = RT6096::One @RT6609::A2::ISA is updated to RT66096::A1, RT66096::Two, RT66096 @RT66096::A1::ISA is set to RT6096::One => so @RT6609::A3::ISA really But in perl-5.8.8 the calls goes to RT66096::Two and in perl-5.10.0 to I believe the behaviour in perl-5.10.0 is 'correct' and the behaviour Best regards, Bram |
From p5p@spam.wizbit.beOn Mon Jun 01 11:23:48 2009, animator wrote:
It looks like RT dropped my attachment for some reason... (rt-66096-
Best regards, Bram |
From p5p@spam.wizbit.beOn Mon Jun 01 11:23:48 2009, animator wrote:
Trimmed it some more.. [snip]
(After thinking about it some more and reading the Class::C3 Looking at the inherintance tree: RT66096::One When the mro is set to Class::C3 then it should never call When the attached script is run as is then it outputs: 5.008008 5.010000 If the commented line is enabled: 5.008008 5.010000 Summary: In perl-5.10.0 mro::set_mro(__PACKAGE__, 'c3') is needed in Unanswered question: what is the correct/expected behaviour? Best regards, Bram |
From [Unknown Contact. See original ticket]On Mon Jun 01 11:23:48 2009, animator wrote:
Trimmed it some more.. [snip]
(After thinking about it some more and reading the Class::C3 Looking at the inherintance tree: RT66096::One When the mro is set to Class::C3 then it should never call When the attached script is run as is then it outputs: 5.008008 5.010000 If the commented line is enabled: 5.008008 5.010000 Summary: In perl-5.10.0 mro::set_mro(__PACKAGE__, 'c3') is needed in Unanswered question: what is the correct/expected behaviour? Best regards, Bram |
From p5p@spam.wizbit.beOn Mon Jun 01 13:04:26 2009, animator wrote:
[snip]
[snip] Replying on myself again... - RT66096::One defines the method mk_group_accessors - mro of RT66096::A2 to c3, What I believe is happening: When the MRO::Compat is used (meaning on perl < 5.9.5) then Class::C3 When the MRO::Compat code is not used (meaning on perl >= 5.9.5) it In the attached test script there are two scenarions: or the lines With #TEST1: 5.010000 With #TEST2: 5.010000 So the mismatch is: On perl < 5.9.5 it sort of 'checks' the mro type of RT66096::Test and (mro.c has always behaved like this) This means that either MRO::Compat/Class::C3 has to change or mro.c has Best regards, Bram |
From [Unknown Contact. See original ticket]On Mon Jun 01 13:04:26 2009, animator wrote:
[snip]
[snip] Replying on myself again... - RT66096::One defines the method mk_group_accessors - mro of RT66096::A2 to c3, What I believe is happening: When the MRO::Compat is used (meaning on perl < 5.9.5) then Class::C3 When the MRO::Compat code is not used (meaning on perl >= 5.9.5) it In the attached test script there are two scenarions: or the lines With #TEST1: 5.010000 With #TEST2: 5.010000 So the mismatch is: On perl < 5.9.5 it sort of 'checks' the mro type of RT66096::Test and (mro.c has always behaved like this) This means that either MRO::Compat/Class::C3 has to change or mro.c has Best regards, Bram |
From blblack@gmail.comI've trimmed down the test-case script above even further (see Correct behavior, as exhibited by 5.10, is that when calling a method on ika:c3bug blblack$ perl rt-66096-5.pl ; ~/P/bin/perl rt-66096-5.pl This needs to be solved over on CPAN in Class::C3 and/or various related |
From @nwc10Given that Brandon diagnosed this difference of behaviour between 5.10's Sadly we don't (yet) have the facility to migrate bugs between Nicholas Clark |
From [Unknown Contact. See original ticket]Given that Brandon diagnosed this difference of behaviour between 5.10's Sadly we don't (yet) have the facility to migrate bugs between Nicholas Clark |
@nwc10 - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#66096 (status was 'resolved')
Searchable as RT66096$
The text was updated successfully, but these errors were encountered: