Bug #130941 for MooX-Enumeration: Latest Moo causes breakage

Thu Nov 07 20:12:21 2019 djerius [...] cpan.org - Ticket created

Subject:

Latest Moo causes breakage

Moo 2.003004 package MyApp::Result; use Moo; use MooX::Enumeration; use Types::Standard qw(Enum); has status => ( is => "rw", isa => Enum[qw/ pass fail /], handles => [qw/ is_pass is_fail /], ); 1; results in: $ perl tst2.pl MyApp::Result doesn't have a `has` function at tst2.pl line 3. BEGIN failed--compilation aborted at tst2.pl line 3.

Fri Nov 08 10:47:25 2019 djerius [...] cpan.org - Correspondence added

On Thu Nov 07 20:12:21 2019, DJERIUS wrote: Show quoted text

> Moo 2.003004 > > package MyApp::Result; > use Moo; > use MooX::Enumeration; > use Types::Standard qw(Enum); > > has status => ( > is => "rw", > isa => Enum[qw/ pass fail /], > handles => [qw/ is_pass is_fail /], > ); > 1; > > results in: > > $ perl tst2.pl > MyApp::Result doesn't have a `has` function at tst2.pl line 3. > BEGIN failed--compilation aborted at tst2.pl line 3. >

See suggested fix at https://github.com/tobyink/p5-moox-enumeration/pull/3

Fri Nov 08 11:41:38 2019 haarg [...] haarg.org - Correspondence added

Please stop poking the internals like this. non_methods is absolutely not meant to be used that way, and there is no guarantee it will have the exports listed in it. I'm likely to restore the 'export' key for backwards compatibility, but also provide better ways to get access to the exports.

Fri Nov 08 11:41:38 2019 The RT System itself - Status changed from 'new' to 'open'

Fri Nov 08 13:16:03 2019 djerius [...] cpan.org - Correspondence added

On Fri Nov 08 11:41:38 2019, haarg wrote: Show quoted text

> Please stop poking the internals like this. non_methods is absolutely > not meant to be used that way, and there is no guarantee it will have > the exports listed in it. > > I'm likely to restore the 'export' key for backwards compatibility, > but also provide better ways to get access to the exports.

No arguments here, but I don't have much of a choice as I need to get my own code working after the latest Moo update, and unfortunately can't wait for a more appropriate fix. So, consider this a hot fix made available to those like myself who need an immediate solution. I have every faith in TOBYINK's doing the right thing in the long run. In any case, there seems to be an awful lot of poking around at Moo's innards by various parties who have written some really useful code, so it might be useful to set down some rules as to what's permissible. Thanks for your efforts on Moo and friends. It's always appreciated.

Fri Nov 08 16:36:24 2019 haarg [...] haarg.org - Correspondence added

On Fri Nov 08 13:16:03 2019, DJERIUS wrote: Show quoted text

> On Fri Nov 08 11:41:38 2019, haarg wrote:

> > Please stop poking the internals like this. non_methods is > > absolutely > > not meant to be used that way, and there is no guarantee it will have > > the exports listed in it. > > > > I'm likely to restore the 'export' key for backwards compatibility, > > but also provide better ways to get access to the exports.

> > > No arguments here, but I don't have much of a choice as I need to get > my own code working after the latest Moo update, and unfortunately

Can you explain what you are doing in your own code that this makes sense? Show quoted text

> can't wait for a more appropriate fix. So, consider this a hot fix > made available to those like myself who need an immediate solution. I > have every faith in TOBYINK's doing the right thing in the long run. > > In any case, there seems to be an awful lot of poking around at Moo's > innards by various parties who have written some really useful code, > so it might be useful to set down some rules as to what's permissible. > > Thanks for your efforts on Moo and friends. It's always appreciated.

Fri Nov 08 17:42:59 2019 djerius [...] cpan.org - Correspondence added

On Fri Nov 08 16:36:24 2019, haarg wrote: Show quoted text

> On Fri Nov 08 13:16:03 2019, DJERIUS wrote:

> > On Fri Nov 08 11:41:38 2019, haarg wrote:

> > > Please stop poking the internals like this. non_methods is > > > absolutely > > > not meant to be used that way, and there is no guarantee it will have > > > the exports listed in it. > > > > > > I'm likely to restore the 'export' key for backwards compatibility, > > > but also provide better ways to get access to the exports.

> > > > > > No arguments here, but I don't have much of a choice as I need to get > > my own code working after the latest Moo update, and unfortunately

> > Can you explain what you are doing in your own code that this makes sense? >

I think something got lost in translation somewhere. I'm not doing anything in my own code. I don't touch any Moo internals. Look at the example code that I provided in the initial bug report. I'm just a user of MooX::Enumeration that needs it to work with the latest release of Moo.

Fri Nov 08 18:30:16 2019 perl [...] toby.ink - Correspondence added

In MooX::Press, I get the `has` function from the tracked exports thing if it exists, and otherwise, I do basically this: my $has = eval "{ package $thepackage; use Moo; my \$coderef = \\&has; no Moo; \$coderef }"; But in MooX::Press, I have more control over the class in question, so I can safely re-import and unimport Moo, knowing it's not going to break anything, etc. That probably wouldn't work so well for MooX::Enumeration.

Sun Nov 10 14:36:38 2019 perl [...] toby.ink - Correspondence added

Accepted Diab's patch as a stop-gap solution until a better method is available.

Sun Nov 10 14:36:38 2019 perl [...] toby.ink - Status changed from 'open' to 'resolved'

Fri Nov 15 10:54:12 2019 djerius [...] cpan.org - Correspondence added

On Sun Nov 10 14:36:38 2019, TOBYINK wrote: Show quoted text

> Accepted Diab's patch as a stop-gap solution until a better method is > available.

Thanks!