Skip Menu |
 

This queue is for tickets about the List-MoreUtils CPAN distribution.

Report information
The Basics
Id: 94013
Status: resolved
Priority: 0/
Queue: List-MoreUtils

People
Owner: Nobody in particular
Requestors: perl [...] toby.ink
willert [...] gmail.com
Cc: ether [...] cpan.org
perl [...] toby.ink
AdminCc:

Bug Information
Severity: Critical
Broken in:
  • 0.400_001
  • 0.400_002
  • 0.400_003
Fixed in: (no value)



CC: mail [...] tobyinkster.co.uk
Subject: Provide fallback for generated methods
Download (untitled) / with headers
text/plain 481b
Some modules on CPAN, and I bet lots of DarkPAN uses List::MoreUtils like this: require List::MoreUtils; List::MoreUtils::all( sub{}, @list ); I've been guilty of that myself in a few places. I'm not sure how this can be supported, but I hope it is okay to add tobyink of Exporter::Tiny, as this might simply be a feature / doc request for Exporter::Tiny as well. I can imagine this is quite a common problem for people switching their dists from Exporter to Exporter::Tiny.
By the way: this also breaks Moose >2.10000 and leads to really strange smoke reports
Download (untitled) / with headers
text/plain 198b
On 2014-03-19 10:12:08, WILLERT wrote: Show quoted text
> By the way: this also breaks Moose >2.10000 and leads to really > strange smoke reports
This is a very big deal - we can't break existing releases of Moose!
Download (untitled) / with headers
text/plain 312b
On Wed Mar 19 13:12:08 2014, WILLERT wrote: Show quoted text
> By the way: this also breaks Moose >2.10000 and leads to really > strange smoke reports
For reference: http://www.cpantesters.org/cpan/report/9eda717a-af5b-11e3-85be-d6547fda8cd6 DBIx::Class::EasyFixture::Definition line 191 is: __PACKAGE__->meta->make_immutable;
RT-Send-CC: mail [...] tobyinkster.co.uk
Download (untitled) / with headers
text/plain 496b
List::MoreUtils never supported function being called as methods. Given you want List::MoreUtils::all - which 'all' do you want? The one from Tassilo as it was made years ago, the one from alias which is a fragile hack of the original one with obscure behavior in edge cases? Or the formula one from leonerd (List::Util) identified by ':modern'. You can choose one. The reason of developer releases is to give dependend packages a chance to adapt when undocumented features don't work anymore.
Download (untitled) / with headers
text/plain 1.5k
On Thu Mar 20 02:38:23 2014, REHSACK wrote: Show quoted text
> List::MoreUtils never supported function being called as methods.
List::MoreUtils::all() is a function call, not a method call, and a well established way to call functions in Perl. The documentation of List::MoreUtils never discouraged its usage. Show quoted text
> Given you want List::MoreUtils::all - which 'all' do you want? The one > from Tassilo as it was made years ago, the one from alias which is a > fragile hack of the original one with obscure behavior in edge cases? > Or the formula one from leonerd (List::Util) identified by ':modern'. > > You can choose one.
How about the one that was current as of 0.33? It worked well enough for what we have been doing with it? Show quoted text
> The reason of developer releases is to give dependend packages a > chance to adapt when undocumented features don't work anymore.
The reason of developer releases is also to gather feedback from the community, utilize the smoke tests and to try not to break to much stuff of other people. Here is your feedback: this change would potentially break at least 2,252 [1] CPAN modules in a really hard to track down fashion. Even if Moose adapts to the new way of doing things, pulling List::MoreUtils 0.40 into an existing library with an older version of Moose would render the whole library almost unusable with no clear indication of what is needed to fix it. Is this really what you want just to teach people that they should not break encapsulation? [1] https://metacpan.org/requires/distribution/Moose?sort=[[2,1]]
Download (untitled) / with headers
text/plain 2.5k
On Thu Mar 20 06:11:23 2014, WILLERT wrote: Show quoted text
> On Thu Mar 20 02:38:23 2014, REHSACK wrote:
> > List::MoreUtils never supported function being called as methods.
> > List::MoreUtils::all() is a function call, not a method call, and a > well established way to call functions in Perl. The documentation of > List::MoreUtils never discouraged its usage.
It neither discouraged using List::MoreUtils::bootstrap - nevertheless you might accept that it's not possible to discourage all possible side-effects. You might also agree to the general assumption that it's not possible to discourage everything unintended usage. Show quoted text
> > Given you want List::MoreUtils::all - which 'all' do you want? The > > one > > from Tassilo as it was made years ago, the one from alias which is a > > fragile hack of the original one with obscure behavior in edge cases? > > Or the formula one from leonerd (List::Util) identified by ':modern'. > > > > You can choose one.
> > How about the one that was current as of 0.33? It worked well enough > for what we have been doing with it?
No. Read RT#40905 for reasons. Show quoted text
> > The reason of developer releases is to give dependend packages a > > chance to adapt when undocumented features don't work anymore.
> > The reason of developer releases is also to gather feedback from the > community, utilize the smoke tests and to try not to break to much > stuff of other people. Here is your feedback: this change would > potentially break at least 2,252 [1] CPAN modules in a really hard to > track down fashion.
I have to make a choice: braking behaviour of documented usage or possible break behavior of undocumented usage. Now I know, I break behavior of undocumented usage - but to be true: I read your concern and I say: there're ways to work around using namespace::clean, relying on List::MoreUtils::Impl::* etc. Pick one - but do not blame me for that, sorry. Show quoted text
> Even if Moose adapts to the new way of doing things, pulling > List::MoreUtils 0.40 into an existing library with an older version of > Moose would render the whole library almost unusable with no clear > indication of what is needed to fix it. Is this really what you want > just to teach people that they should not break encapsulation? > > [1] https://metacpan.org/requires/distribution/Moose?sort=[[2,1]]
See http://blog.stratopan.com/2014/01/please-dont-let-me-break-your-code/ Stop flaming - and we might be able to find a solution. I don't argue in that tone. You're going to rely on undocumented feature - and now you that bites you and you want me taking responsibility of it? Sorry!. Cheers, Jens
Download (untitled) / with headers
text/plain 770b
I don't see this as an Exporter::Tiny issue, as no exporting is being done. It's an issue with the overall design of LMU 0.4x, where there is no longer a List::MoreUtils::all() function that can be called. One solution would be for List::MoreUtils to provide an AUTOLOAD function that could delegate to an appropriate implementation of the function. However, this would be unnecessarily slow (introduces an extra level of sub call), and fragile if people are doing stuff like: my $all = UNIVERSAL::can('List::MoreUtils', 'all'); $all->($coderef, @list); A better solution would be for LMU to just import its own functions so that it can offer them under their fully-qualified names. Just add this somewhere to MoreUtil.pm: __PACKAGE__->import( -all );
Download (untitled) / with headers
text/plain 1.7k
On Thu Mar 20 06:37:46 2014, REHSACK wrote: Show quoted text
> On Thu Mar 20 06:11:23 2014, WILLERT wrote:
> > On Thu Mar 20 02:38:23 2014, REHSACK wrote:
> > > List::MoreUtils never supported function being called as methods.
> > > > List::MoreUtils::all() is a function call, not a method call, and a > > well established way to call functions in Perl. The documentation of > > List::MoreUtils never discouraged its usage.
> > It neither discouraged using List::MoreUtils::bootstrap - nevertheless > you might accept that it's not possible to discourage all possible > side-effects. > > You might also agree to the general assumption that it's not possible > to discourage everything unintended usage.
I accept that. Where we disagree is that calling a function via its full namespace instead of importing it into your own is in any way unusual or undocumented. From time to time I also have seen it encouraged to keep your namespace clean without depending on namespace::clean and friends. Show quoted text
> > > Given you want List::MoreUtils::all - which 'all' do you want? The > > > one > > > from Tassilo as it was made years ago, the one from alias which is > > > a > > > fragile hack of the original one with obscure behavior in edge > > > cases? > > > Or the formula one from leonerd (List::Util) identified by > > > ':modern'. > > > > > > You can choose one.
> > > > How about the one that was current as of 0.33? It worked well enough > > for what we have been doing with it?
> > No. Read RT#40905 for reasons.
We agree that it is broken, I just think it is possible to fix it without breaking other peoples stuff as a side-effect of trying to fix it. Do you think Tobys proposed solution is workable? As far as I can tell it would solve this problem quite elegantly. Cheers, Sebastian
Download (untitled) / with headers
text/plain 520b
Exporter::Tiny does support %EXPORT_TAGS (and @EXPORT and @EXPORT_OK) however my patch to port LMU to Exporter::Tiny doesn't make use of it because the tags require somewhat more complex handling ("all" exported by the ":modern" tag is expected to be different to "all" exported by the ":tasillo" tag). Adding something like this: our %EXPORT_TAGS = map { $_ => [ keys %{ $pkg_tags{$_}{functions} } ] } keys %pkg_tags; $EXPORT_TAGS{all} = \@EXPORT_OK; Should provide a sensible %EXPORT_TAGS for List::AllUtils to use.
Sorry, this was supposed to be a reply to #93995. I don't have permission to merge the tickets.
Download (untitled) / with headers
text/plain 281b
I follow tobyink's recommendation using __PACKAGE__->import(':all') for a very short time to allow authors to fix their modules using the new API of LMU. I hacked the tests for it already and will add a hint in documentation that require is discouraged and how to adapt your code.
Download (untitled) / with headers
text/plain 130b
First approach for near future in 0.400_004. I hope we have a constructive discussion soon how to long-term-deal with that issue.
Download (untitled) / with headers
text/plain 1.7k
On Fri Mar 21 07:41:42 2014, REHSACK wrote: Show quoted text
> First approach for near future in 0.400_004. > > I hope we have a constructive discussion soon how to long-term-deal > with that issue.
Thanks for applying the fix for 0.400. I still have problems seeing your rational for removing the possibility of using List::MoreUtils via require. As far as I can tell importing LMU into its own namespace solves everything cleanly and with just one line of code (and two lines of comments explaining why it is done). With this fix, the somewhat wide-spread usage of LMU as require List::MoreUtils; List::MoreUtils::all([...]); (and variations thereof) is functionally equivalent to use List::MoreUtils qw/:all/; all([...]); Isn't that what you want? Keep in mind, that there are use-cases in which the reliance on ->import is at least impractical. E.g.: require List::MoreUtils; my $class = Moose::Meta::Class->create( Foo => ( methods => { bar => sub{ List::MoreUtils::all([...]); }} )); is straight-forward, while I am having a hard time figuring out how to do same sanely with import. I don't say it can't be done (I see at least three more complicated ways of achieving similar results), I'm just trying to show you an in my opinion perfectly legitimate way to use LMU that relies on require instead of ->import. Granted: this particular piece of code would work with ->import, but only because perl would resolve &all to mean &__PACKAGE__::all which seems very fragile to me, breaks all kinds of best encapsulation practices and would e.g. prohibit having an 'all' function in the "host" namespace. As I said, I don't see a compelling reason to get rid of require, and at least a few reasons (potentially breaking tons of legacy installs is just the biggest) to keep it around. Cheers, Sebastian
Subject: Re: [rt.cpan.org #94013] Provide fallback for generated methods
Date: Fri, 21 Mar 2014 16:34:49 +0100
To: bug-List-MoreUtils [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] gmail.com>
Download (untitled) / with headers
text/plain 4.3k
Am 21.03.2014 um 14:34 schrieb Sebastian Willert via RT <bug-List-MoreUtils@rt.cpan.org>: Show quoted text
> Queue: List-MoreUtils > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=94013 > > > On Fri Mar 21 07:41:42 2014, REHSACK wrote:
>> First approach for near future in 0.400_004. >> >> I hope we have a constructive discussion soon how to long-term-deal >> with that issue.
> > Thanks for applying the fix for 0.400.
Naming it a hotfix and call it a day :) Show quoted text
> I still have problems seeing your rational for removing the possibility of using List::MoreUtils via require. As far as I can tell importing LMU into its own namespace solves everything cleanly and with just one line of code (and two lines of comments explaining why it is done).
This has to do with the history and the API breakage by self-volunteered maintainer. I now have to cleanup the mess he left - and I had to make a choice. While ether and ribasushi voted strongly against immediate API change, the only other option was a depreciation of the broken API and a slow move while giving users the option to choose. Does it explain? If not, you should join IRC (probably with some other Moose colleagues, because I don’t intend to have the same 30min talk in IRC more often then necessary ^^). Show quoted text
> With this fix, the somewhat wide-spread usage of LMU as > require List::MoreUtils; List::MoreUtils::all([...]); > (and variations thereof) is functionally equivalent to > use List::MoreUtils qw/:all/; all([...]); > Isn't that what you want?
Sorry to say - it’s not. ›use List::MoreUtils 'any‘‹ currently means ›use List::MoreUtils 'any‘ => { impl => 'alias' }‹, but in a few month it’ll mean ›use List::MoreUtils 'any‘ => { impl => ’tassilo' }‹. Show quoted text
> Keep in mind, that there are use-cases in which the reliance > on ->import is at least impractical. E.g.: > > require List::MoreUtils; > my $class = Moose::Meta::Class->create( Foo => ( > methods => { bar => sub{ List::MoreUtils::all([...]); }} > ));
require List::MoreUtils; my $class = Moose::Meta::Class->create( Foo => ( methods => { bar => sub{ (List::MoreUtils->_exporter_expand_sub('all‘, {impl => ’tassilo'}))[1]->(...); }} )); require List::MoreUtils; my $all = (List::MoreUtils->_exporter_expand_sub('all‘, {impl => ’tassilo'}))[1]; my $class = Moose::Meta::Class->create( Foo => ( methods => { bar => sub{ $all->(...); }} )); require List::MoreUtils::Impl::Alias; my $class = Moose::Meta::Class->create( Foo => ( methods => { bar => sub{ List::MoreUtils::Impl::Alias::all(...); }} )); You see, timtowtdoi Show quoted text
> is straight-forward, while I am having a hard time figuring out how to do same sanely with import. I don't say it can't be done (I see at least three more complicated ways of achieving similar results), I'm just trying to show you an in my opinion perfectly legitimate way to use LMU that relies on require instead of ->import.
And if it would be acceptable to switch immediately from the broken API back to the original one without breaking other modules, I would agree. But thanks to - let’s say an accident - we’re now in trouble and that causes the loose-loose-situation you’ve also joined :) And "but many modules needs ...“ is an argument for both sides. 0.4xx has the approach to give ages users a way to keep their environments sane and their algorithms stable as well as don’t break well maintained recent code. Unfortunately permitting the „require“ use-case will pretend a kind of safety and/or stability which isn’t there. Show quoted text
> Granted: this particular piece of code would work with ->import, but only because perl would resolve &all to mean &__PACKAGE__::all which seems very fragile to me, breaks all kinds of best encapsulation practices and would e.g. prohibit having an 'all' function in the "host" namespace. > > As I said, I don't see a compelling reason to get rid of require, and at least a few reasons (potentially breaking tons of legacy installs is just the biggest) to keep it around.
I hope I could help you with those explanations - additionally I added a rough overview to 0.400_004 pod and don’t intend to remove quickly. TL;DR: * as Tassilo I have the approach to do the things "right“ - not easy. * this means reverting introduced API pollution * this means breaking code relying on documented behavior when doing the easy way (one function, use == require+import) Cheers -- Jens Rehsack rehsack@gmail.com
Download (untitled) / with headers
text/plain 2.2k
On Fri Mar 21 11:35:01 2014, rehsack@gmail.com wrote: Show quoted text
>
> > I still have problems seeing your rational for removing the > > possibility of using List::MoreUtils via require. As far as I can > > tell importing LMU into its own namespace solves everything cleanly > > and with just one line of code (and two lines of comments explaining > > why it is done).
> > This has to do with the history and the API breakage by self- > volunteered maintainer. > I now have to cleanup the mess he left - and I had to make a choice. > While ether and ribasushi voted strongly against immediate API change, > the only other option was a depreciation of the broken API and a slow > move while giving users the option to choose.
You stil seem to misunderstand me. I don't want to keep the broken state of version 0.33, I just want to have the functions that are exported by 'use List::MoreUtils qw/:all/;' to be also available via the List::MoreUtils namespace so they can be used via require. I can't see how this would impede your ability to change the API or the implementation details at will, it will just keep lots of code that is already out there running (in almost all cases). In a nutshell, I am arguing that the next version of List::MoreUtils should still be usable when loaded at run-time, which has been the case since the dawn of time (like 10 years ago when it was first released). You may think, that run-time stuff is inherently unsafe and should be discouraged, but you should not go ahead and prove that point by intentionally breaking it. Show quoted text
> Does it explain? If not, > you should join IRC (probably with some other Moose colleagues, > because I don’t intend to have the same 30min talk in IRC more often > then necessary ^^).
Then lets keep this discussion here so other people can look up what has already been discussed :) By the way, I am not affiliated with Moose in any way, just an heavy user. Show quoted text
> Unfortunately permitting the „require“ use-case will pretend a kind of > safety and/or stability which isn’t there.
As far as I can see it would be exactly as stable and safe as 'use List::MoreUtils qw/:all/;' with the sole exception, that you don't get compile-time checking of the availability of functions that might have been removed. But you would already knew this as a user because this is inherent in using require.
Subject: Re: [rt.cpan.org #94013] Provide fallback for generated methods
Date: Fri, 21 Mar 2014 17:31:44 +0100
To: bug-List-MoreUtils [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] gmail.com>
Download (untitled) / with headers
text/plain 2.9k
Am 21.03.2014 um 17:25 schrieb Sebastian Willert via RT <bug-List-MoreUtils@rt.cpan.org>: Show quoted text
> Queue: List-MoreUtils > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=94013 > > > On Fri Mar 21 11:35:01 2014, rehsack@gmail.com wrote:
>>
>>> I still have problems seeing your rational for removing the >>> possibility of using List::MoreUtils via require. As far as I can >>> tell importing LMU into its own namespace solves everything cleanly >>> and with just one line of code (and two lines of comments explaining >>> why it is done).
>> >> This has to do with the history and the API breakage by self- >> volunteered maintainer. >> I now have to cleanup the mess he left - and I had to make a choice. >> While ether and ribasushi voted strongly against immediate API change, >> the only other option was a depreciation of the broken API and a slow >> move while giving users the option to choose.
> > You stil seem to misunderstand me. I don't want to keep the broken state of version 0.33, I just want to have the functions that are exported by 'use List::MoreUtils qw/:all/;' to be also available via the List::MoreUtils namespace so they can be used via require. I can't see how this would impede your ability to change the API or the implementation details at will, it will just keep lots of code that is already out there running (in almost all cases).
This implies not recognizing when things change. I also intend to remove ':all‘ sooner or later, to force people making their choice. But I also listen to your arguments (as well as to ether and ribasushi) who say: „keep behavior“ - and try to solve. Show quoted text
> In a nutshell, I am arguing that the next version of List::MoreUtils should still be usable when loaded at run-time, which has been the case since the dawn of time (like 10 years ago when it was first released). You may think, that run-time stuff is inherently unsafe and should be discouraged, but you should not go ahead and prove that point by intentionally breaking it.
I agree. I do not break it now but discourage it, then discourage with warning and then break. Show quoted text
>> Does it explain? If not, >> you should join IRC (probably with some other Moose colleagues, >> because I don’t intend to have the same 30min talk in IRC more often >> then necessary ^^).
> > Then lets keep this discussion here so other people can look up what has already been discussed :) > > By the way, I am not affiliated with Moose in any way, just an heavy user. >
>> Unfortunately permitting the „require“ use-case will pretend a kind of >> safety and/or stability which isn’t there.
> > As far as I can see it would be exactly as stable and safe as 'use List::MoreUtils qw/:all/;' with the sole exception, that you don't get compile-time checking of the availability of functions that might have been removed. But you would already knew this as a user because this is inherent in using require.
I also agree here - and I think about to couple the both depreciations … Cheers -- Jens Rehsack rehsack@gmail.com
Download (untitled) / with headers
text/plain 1.1k
On Fri Mar 21 07:41:42 2014, REHSACK wrote: Show quoted text
> First approach for near future in 0.400_004. > > I hope we have a constructive discussion soon how to long-term-deal > with that issue.
Honestly, while I do understand that you're trying to balance different sorts of breakage, it's a general assumption by people that statically exporting things, unless specifically noted otherwise, also provide their subroutines via direct access. Basically, while I see your point that it isn't documented *to* work, my general expectation of CPAN code is that it *will* unless explicitly documented as not permitted, since that's how exporters (especially Exporter using exporters) normally work. Now, if List::MoreUtils::all() is going to change behaviour slightly in the name of sanity, having that happen might be reasonable - but causing it to cease existence is a huge violation of POLS and IMO a massive backcompat breakage in spirit even if the absence of explicit documentation either way means it isn't a backcompat breakage in letter. I suspect this was the idea that people were trying to express to you but was somewhat obscured by their ... suboptimal tone due to having just experienced a very nasty surprise.
Subject: Re: [rt.cpan.org #94013] Provide fallback for generated methods
Date: Fri, 21 Mar 2014 17:53:10 +0100
To: bug-List-MoreUtils [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] gmail.com>
Am 21.03.2014 um 17:39 schrieb MSTROUT via RT <bug-List-MoreUtils@rt.cpan.org>: Show quoted text
> Queue: List-MoreUtils > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=94013 > > > On Fri Mar 21 07:41:42 2014, REHSACK wrote:
>> First approach for near future in 0.400_004. >> >> I hope we have a constructive discussion soon how to long-term-deal >> with that issue.
> > Honestly, while I do understand that you're trying to balance different sorts of breakage, it's a general assumption by people that statically exporting things, unless specifically noted otherwise, also provide their subroutines via direct access.
Which is the reason for the 0.400_004 hot fix. I fully agree to the assumption and way of work in general. Show quoted text
> Basically, while I see your point that it isn't documented *to* work, my general expectation of CPAN code is that it *will* unless explicitly documented as not permitted, since that's how exporters (especially Exporter using exporters) normally work. > > Now, if List::MoreUtils::all() is going to change behaviour slightly in the name of sanity, having that happen might be reasonable - but causing it to cease existence is a huge violation of POLS and IMO a massive backcompat breakage in spirit even if the absence of explicit documentation either way means it isn't a backcompat breakage in letter.
Point taken :) Show quoted text
> I suspect this was the idea that people were trying to express to you but was somewhat obscured by their ... suboptimal tone due to having just experienced a very nasty surprise.
Always when I’m in the bathroom I see the one who is specialist in suboptimal tone. Having a vengeful attitude helps a lot :D As said: I’m open for suggestions - but I really like when contributors take the responsibility to discuss (and I don’t say „Matt has to do“ - ether, haarg, rjbs, willert, pjcj, garu, … can also do). But someone has to - otherwise I might make mistakes as that one again :) The ribasushi solution „let it die“ isn’t acceptable to me :D Cheers -- Jens Rehsack rehsack@gmail.com
Download (untitled) / with headers
text/plain 631b
On Fri Mar 21 12:53:22 2014, rehsack@gmail.com wrote: Show quoted text
> > I suspect this was the idea that people were trying to express to you > > but was somewhat obscured by their ... suboptimal tone due to having > > just experienced a very nasty surprise.
> > Always when I’m in the bathroom I see the one who is specialist in > suboptimal tone. Having a vengeful attitude helps a lot :D
Sometimes I get the feeling this comes for free with being from Germany ;) [I am from there, too] Anyways, thanks for listening to us, and for trying to improve the state of things. As we say: "Wo gehobelt wird fallen Späne" :) Cheers, Sebastian
Download (untitled) / with headers
text/plain 283b
On Fri Mar 21 13:31:23 2014, WILLERT wrote: Show quoted text
> Sometimes I get the feeling this comes for free with being from > Germany ;) [I am from there, too]
There's a reason a significant percentage of my friends are part German. Though that's more about them tolerating me than vice versa ;)
Download (untitled) / with headers
text/plain 609b
On Fri Mar 21 12:53:22 2014, rehsack@gmail.com wrote: Show quoted text
> As said: I’m open for suggestions - but I really like when > contributors take the responsibility to discuss (and I don’t say „Matt > has to do“ - ether, haarg, rjbs, willert, pjcj, garu, … can also do).
I think posting an RFC publically somewhere is probably a good way to invite comments, esp. if the post gets linked to #toolchain by somebody. Admittedly, I'll probably still completely miss it until ether /msg's me a link, but given she almost certainly *will* I just have to try and be grateful enough for it that she keeps doing that.
Subject: Re: [rt.cpan.org #94013] Provide fallback for generated methods
Date: Fri, 21 Mar 2014 20:27:12 +0100
To: bug-List-MoreUtils [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] gmail.com>
Am 21.03.2014 um 19:50 schrieb MSTROUT via RT <bug-List-MoreUtils@rt.cpan.org>: Show quoted text
> Queue: List-MoreUtils > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=94013 > > > On Fri Mar 21 12:53:22 2014, rehsack@gmail.com wrote:
>> As said: I’m open for suggestions - but I really like when >> contributors take the responsibility to discuss (and I don’t say „Matt >> has to do“ - ether, haarg, rjbs, willert, pjcj, garu, … can also do).
> > I think posting an RFC publically somewhere is probably a good way to invite comments, esp. if the post gets linked to #toolchain by somebody. > > Admittedly, I'll probably still completely miss it until ether /msg's me a link, but given she almost certainly *will* I just have to try and be grateful enough for it that she keeps doing that.
There’re two reasonable places: 1) RT Queue (dedicated ticket or this ticket) 2) PerlMonks Generally I do not intend spec LMU - it _is_ a small footprint package. Some people who would agree being sounding board or a mailing list or alike would be helpful. Cheers -- Jens Rehsack rehsack@gmail.com
Download (untitled) / with headers
text/plain 708b
On Fri Mar 21 15:27:29 2014, rehsack@gmail.com wrote: Show quoted text
> Generally I do not intend spec LMU - it _is_ a small footprint > package. > Some people who would agree being sounding board or a mailing list or > alike would be helpful.
Make no mistake, LMU may be low footprint, but it is still very high profile: as of http://ali.as/top100/ it is around #10 in most-depended upon modules that is neither in the toolchain nor dual-lived :) I'd volunteer as sounding board [and I assure you, I sound a bit friendlier when writing german ;)] but I still think there should be a public discussion for significant changes, seeing how many people would be affected. Feel free to email me directly. Cheers, Sebastian
Download (untitled) / with headers
text/plain 913b
On Fri Mar 21 15:27:29 2014, rehsack@gmail.com wrote: Show quoted text
> There’re two reasonable places: > > 1) RT Queue (dedicated ticket or this ticket) > 2) PerlMonks > > Generally I do not intend spec LMU - it _is_ a small footprint > package. > Some people who would agree being sounding board or a mailing list or > alike would be helpful.
I cannot stand the perlmonks UI and my mail setup is completely fucked in terms of being able to handle lists. Equally, enough other people may be able to respond on a list that my technical failings aren't an issue. I sort of wonder if "dump it into PTG and use github issues" might not be a reasonable approach, since unlike RT we can have people who aren't co-maints auto-notified of new tickets, and LMU kinda feels like toolchain-level important to me. Of course, if you want a direct sounding bored before doing other stuff, 'grab me on IRC' is a good solution as always.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.