Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: REHSACK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.400_005



Subject: Kindly name the available implementations
Haarg@ wasn't satisfied by naming implementations by author. This ticket is for finding better names and associations.
On Sat Mar 22 07:52:28 2014, REHSACK wrote: Show quoted text
> Haarg@ wasn't satisfied by naming implementations by author. > > This ticket is for finding better names and associations.
I have two problems with the current names. First is that they provide no useful information about their different behaviors. You would have to reference the documentation every time to know what the intention is. Second is that they are inaccurate. The behavior change that lead to this issue is RT#40905. The change was made in 2009 by the original author, Tassilo, for version 0.24. It was then accidentally reverted during a maintainership shuffle for Adam Kennedy's 0.24 and 0.26 releases. The new behavior was re-introduced in version 0.28, released 2 weeks after the new 0.24. So the behavior change is attributable to Tassilo if anyone.
On Sun Mar 23 12:39:07 2014, haarg wrote: Show quoted text
> On Sat Mar 22 07:52:28 2014, REHSACK wrote:
> > Haarg@ wasn't satisfied by naming implementations by author. > > > > This ticket is for finding better names and associations.
> > I have two problems with the current names. > > First is that they provide no useful information about their different > behaviors. You would have to reference the documentation every time > to know what the intention is. >
Okay, now we know why you're unlucky. I'm open for proposals to match the intension better (and I'm happy to find a way to kick the "sno" impl!). Show quoted text
> Second is that they are inaccurate. The behavior change that lead to > this issue is RT#40905. The change was made in 2009 by the original > author, Tassilo, for version 0.24. It was then accidentally reverted > during a maintainership shuffle for Adam Kennedy's 0.24 and 0.26 > releases. The new behavior was re-introduced in version 0.28, > released 2 weeks after the new 0.24. So the behavior change is > attributable to Tassilo if anyone.
This is wrong. The change Tassilo made in 0.24 is: void any (code,...) SV *code; PROTOTYPE: &@ CODE: { dMULTICALL; register int i; GV *gv; HV *stash; I32 gimme = G_SCALAR; - SV **args = &PL_stack_base[ax]; CV *cv; if (items <= 1) XSRETURN_UNDEF; cv = sv_2cv(code, &stash, &gv, 0); PUSH_MULTICALL(cv); SAVESPTR(GvSV(PL_defgv)); for(i = 1 ; i < items ; ++i) { - GvSV(PL_defgv) = args[i]; + GvSV(PL_defgv) = PL_stack_base[ax+i]; MULTICALL; if (SvTRUE(*PL_stack_sp)) { POP_MULTICALL; XSRETURN_YES; } } POP_MULTICALL; XSRETURN_NO; } Same for most other functions. The change from "undef" to "true/false" has been introduced by Alias.
Providing names ":strict", ":relax" and ":modern" along with precedences ":all" (relax > strict > modern) and ":default" (strict > relax > modern) should solve the requirement of suitable names of the implementations.