[Catalyst-dev] Smoke tests - summary of things which don't work against 5.80

[Tomas Doran]

Florian pointed out on IRC that there are issues with  
CatalystX::Imports which could also prove a problem for darkpan code.

The issue is basically that Class::MOP doesn't like considering anon  
subs in the symbol table as methods, and is demonstrated by  
CX::Imports' test fails..

Not sure if this is a common use-case.. However the issue might be  
tricky to fix, but (at worst) it would be possible if people use'd a  
backcompat module into controllers which needed it...

I've included the relevant section of the irc discussion below,  
lightly edited to make it more succinct / readable.

Cheers
t0m

21:28 < rafl> did we already decide if *foo = sub : Path(/foo/bar)  
{ ... }; not working anymore on 5.80 is a bug or not?
21:30 < rafl> or rather sub foo : ... { } *foo = sub { };
21:30 < rafl> CX::Imports uses something like that to wrap actions
21:38 <@groditi> i don't think that's a bug
21:38 <@groditi> people who have code that breaks will disagree though
21:39 <@groditi> that seems like undefined behavior
21:40 < rafl> i'm undecided about this. i don't really care if it  
breaks imports or something similar on cpan - i can fix that. i'm  
just worried about breaking darkpan code using a similar technique.
21:45 < rafl> the reason for that failing on 5.8 is that cmop says an  
anon coderef in the symbol table is not a method
21:49 <@t0m> does taking Sub::Name to the coderef before stuffing it  
in the typeglob make CMOP dtrt? I'm thinking that you could inspect  
the symbol table for the relevant package and 'fix' any anon subs at  
some point before MOP has a fit..
21:49 <@groditi> rafl: all that needs is sub::name
21:49 <@groditi> t0m: ditto. yeah. it's a common issue, i had to  
Sub::name everything in DBIC to get it to play nice with MOP modifiers
21:50 < rafl> right, but naming the wrapper like the real action  
isn't the right thing to do in cx-imports
21:50 <@groditi> also: modifiers do not work in controllers, which is  
not surprising if you know how it all works, but may grab newbies by  
surprise. next::method need to be used in controllers
21:51 < rafl> or i was being stupid when i tried to fix it that way.  
i can't remember the details :-/
21:52 <@t0m> what is stopping you from Sub::Naming them on import,  
but then removing the symbols on end of scope?
21:53 <@t0m> But I was thinking of a generic solution for darkpan,  
which is a harder problem as you quite possibly don't have an import  
method that is going to get called :/
21:54 < rafl> i don't know. i should revisit that problem. i just  
wanted to point out that we break back-compat somewhat