in reply to What should be returned in scalar context?

I'm with Abigail-II here. I don't think it's useful to standardize on a behavior when dwimmery is involved. Perl's own functions are not standardized, and I wouldn't want to be held to a standard behavior when my particular function doesn't work that way.

I do think that many of the internals should check for void context, if possible, like what Juerd said (and like what map does). For example, uc (and friends) would be great like that. I hate having to write $x = uc $x; when the dwimmiest way would be uc $x; and have it mutate in void context.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re: What should be returned in scalar context?
by Juerd (Abbot) on Dec 02, 2003 at 17:21 UTC

    I hate having to write $x = uc $x; when the dwimmiest way would be uc $x; and have it mutate in void context.

    The funny (?) thing is that Perl itself is inconsistent when it comes to operators that change strings.
    MutatingNot mutating
    chomp
    chop
    s///
    tr///    		 lc
    lcfirst
    quotemeta
    uc
    ucfirst

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

[reply]

      As of last week, Larry's plan is to make Perl 6 much more consistent in that respect. My speculation (not his official pronouncement) is that there'll be two versions of each operator, one that works in-place and one that returns the modified value, leaving the original untouched.

      It'll probably go further than Ruby's convention of postfixing ! to methods that operate in-place, perhaps having language support for adding this behavior to your own operators.

      It's only in the idea stages, though.

[reply]
[d/l]

In Section Meditations