Re: String increment

Ahem.

($foo, $bar, $date) = qw(fooa bar7 1-OCT-2007-RevA);
print "++foo ++bar ++date\n"
[download]

and saw

foob bar8 1
[download]

Darn clever version of perl have you do, says Yoda. I get ++foo ++bar ++date. You mean

print join(" ",++$foo,++$bar,++$date)
[download]

which yields foob bar8 2.

Why limit the magic to strings that match the pattern. When is it ever better to return '1' than the incremented string?

That magic is a perl dwimmery for special cases, like incrementing filehandles of the form FH000. It is also limited to increment, string decrement isn't implemented.

It is arguably better to return 15 when incrementing 14 floz instead of returning 14 flpa. Here perl rightly (imho) guesses that the number is more important than the unit, which would become nonsensical anyways if incremented.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Comment on Re: String increment - reasoning Select or Download Code

Replies are listed 'Best First'.
Re^2: String increment - reasoning by dsheroh (Monsignor) on Oct 02, 2007 at 15:27 UTC
While I agree with the portion of your "arguably better" about incrementing the number rather than the unit¹, I would still say that returning `15` rather than `15 floz` is broken. I don't really see the benefit to any sort of 'increment one portion of the string and throw the rest away' scheme unless you're actively trying to confuse people by sometimes incrementing and returning the whole value and other times only incrementing and returning part of it. Since there's no real way to get it to reliably do the Right Thing without adding more syntax (e.g., something like `++[1]$foo` for first part, `++[-1]$foo` for the last part), it should at least be immediately clear what happened when it does a Wrong Thing. Incrementing `14 floz` to `15 floz` and `1-OCT-2007-RevA` to `2-OCT-2007-RevA` makes it much clearer what's going on than incrementing them to just `15` and `2`, even aside from the minor detail that the non-truncated results are sometimes correct. ¹ ...although it's really just incrementing the first segment of the value which matches the pattern, which is correct in your example, but incorrect in others	[reply] [d/l] [select]
Re^3: String increment - reasoning by Fletch (Bishop) on Oct 02, 2007 at 16:46 UTC
Incrementing "14 floz" to 15 is sane behavior when compared with Perl's behavior elsewhere when strings are used as numbers (which is if the leading part looks like a number, convert that part to a number and ignore the rest). Not dropping the not-a-number part for increments would be less regular.	[reply]
Re^3: String increment - reasoning by shmem (Chancellor) on Oct 03, 2007 at 21:53 UTC
shrug if you don't want perl to dwim, be explicit, as always. For number operations, there's the rule "it's a number as long as it looks like a number (from left to right)". Incrementig `31-OCT-2007-RevA` what should perl do? `31-OCT-2007-RevB`, `32-OCT-2007-RevA` or `1-NOV-2007-RevA` ? The latter with or without leading zero? How could that decision be reliably coded? --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply] [d/l] [select]
Re^4: String increment - reasoning by eric256 (Parson) on Oct 03, 2007 at 23:39 UTC
That made me pictures a DWIM::Inc module. ;) ___________ Eric Hodges	[reply]