Bug #70539 for Moose: Num should not use looks_like

# Sat Aug 27 15:40:58 2011 rjbs [...] cpan.org - Ticket created

Subject:

Num should not use looks_like_number

Download (untitled) / with headers
text/plain 107b

Num uses "looks_like_number" which accepts " 123 " and "NaN" and "Inf" and other stupid things. -- rjbs

# Fri Nov 23 19:33:26 2012 ether [...] cpan.org - Correspondence added

Download (untitled) / with headers
text/plain 310b

On Sat Aug 27 12:40:58 2011, RJBS wrote: Show quoted text

> Num uses "looks_like_number" which accepts " 123 " and "NaN" and "Inf" > and other stupid things.

What sorts of things should Num accept, and not accept? normally ' 123 ' is happy to numify without warnings - should we not respect that in the constraint as well?

# Fri Nov 23 19:33:27 2012 The RT System itself - Status changed from 'new' to 'open'

# Tue May 21 16:02:56 2013 rt.cpan [...] sartak.org - Correspondence added

Download (untitled) / with headers
text/plain 90b

Num will now be stricter thanks to Upasana Shukla! https://github.com/moose/moose/pull/18

# Tue May 21 16:02:57 2013 rt.cpan [...] sartak.org - Status changed from 'open' to 'resolved'

# Mon May 27 18:45:27 2013 KENTNL [...] cpan.org - Correspondence added

Download (untitled) / with headers
text/html 630b

I think the only thing wrong with this is the documentation doesn't much explain the rationale, from the surface it just looks like "somebody filed a bug so we changed it"

imo, the rationale is basically "Num" should indicate "is a number" not "coerces to a number", and making the distinction means you get more rigorous code, and coercions, if any, should be performed during assignment to the attribute, not every time consuming code evaluates the value.

And if you want attribute coercion, it should be explicit, not implicit.

# Mon Jun 10 20:15:44 2013 ether [...] cpan.org - Correspondence added

Download (untitled) / with headers
text/plain 802b

On 2013-05-27 15:45:27, KENTNL wrote: Show quoted text

> imo, the rationale is basically "Num" should indicate "is a number" > not > "coerces to a number", and making the distinction means you get more > rigorous > code, and coercions, if any, should be performed during assignment to > the > attribute, not every time consuming code evaluates the value. > > And if you want attribute coercion, it should be explicit, not > implicit.

I wholeheartedly agree with these points. Which raises the question in my mind: Should (the new) Num have a coercion defined for Str->Num which uses looks_like_number heuristics to transform to a valid Num (the coercion sub would actually be something like { $_ + 0 }? I don't think any of the builtins have coercions defined for them, but we could easily add some sensible ones.

# Mon Jun 10 20:20:50 2013 doy [...] tozt.net - Correspondence added

Subject:	Re: [rt.cpan.org #70539] Num should not use looks_like_number
Date:	Mon, 10 Jun 2013 19:20:34 -0500
To:	Karen Etheridge via RT <bug-Moose [...] rt.cpan.org>
From:	Jesse Luehrs <doy [...] tozt.net>

Download (untitled) / with headers
text/plain 1.2k

On Mon, Jun 10, 2013 at 08:15:45PM -0400, Karen Etheridge via RT wrote: Show quoted text

> Queue: Moose > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=70539 > > > On 2013-05-27 15:45:27, KENTNL wrote: >

> > imo, the rationale is basically "Num" should indicate "is a number" > > not > > "coerces to a number", and making the distinction means you get more > > rigorous > > code, and coercions, if any, should be performed during assignment to > > the > > attribute, not every time consuming code evaluates the value. > > > > And if you want attribute coercion, it should be explicit, not > > implicit.

> > I wholeheartedly agree with these points. Which raises the question in > my mind: > > Should (the new) Num have a coercion defined for Str->Num which uses > looks_like_number heuristics to transform to a valid Num (the coercion > sub would actually be something like { $_ + 0 }? > > I don't think any of the builtins have coercions defined for them, but > we could easily add some sensible ones.

I think that this is something that could go in the MooseX::Types::LaxNum module that sweet_kid released, but doesn't belong in the core distribution. Coercing from "things that perl can intuit a number out of" doesn't seem to be a particularly useful general purpose thing. -doy

# Mon Jun 10 20:29:33 2013 rjbs [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #70539] Num should not use looks_like_number
Date:	Mon, 10 Jun 2013 20:29:16 -0400
To:	Jesse Luehrs via RT <bug-Moose [...] rt.cpan.org>
From:	Ricardo Signes <rjbs [...] cpan.org>

Download (untitled) / with headers
text/plain 1k

* Jesse Luehrs via RT <bug-Moose@rt.cpan.org> [2013-06-10T20:20:50] Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=70539 > > > On Mon, Jun 10, 2013 at 08:15:45PM -0400, Karen Etheridge via RT wrote:

> > Should (the new) Num have a coercion defined for Str->Num which uses > > looks_like_number heuristics to transform to a valid Num (the coercion > > sub would actually be something like { $_ + 0 }? > > > > I don't think any of the builtins have coercions defined for them, but > > we could easily add some sensible ones.

> > I think that this is something that could go in the > MooseX::Types::LaxNum module that sweet_kid released, but doesn't belong > in the core distribution. Coercing from "things that perl can intuit a > number out of" doesn't seem to be a particularly useful general purpose > thing.

I agree with Jesse, and further note for the record that 0+ and looks_like_number will lead to things that aren't valid Nums. The strings 'Inf' and 'NaN' are looks_like_number and 0+'Inf' is 'inf' -- which gets us back to the mess that started this whole thing rolling. -- rjbs

Download signature.asc
application/pgp-signature 490b

Message body not shown because it is not plain text.

Bug #70539 for Moose: Num should not use looks_like_number