Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^3: Module Announcement: Perl-Critic-1.01 (just a scalar)

by chromatic (Archbishop)
on Jan 26, 2007 at 22:07 UTC ( #596796=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Module Announcement: Perl-Critic-1.01 (just a scalar)
in thread Module Announcement: Perl-Critic-1.01

The reason that the former is wrong is because it can break code like:

Why do you not consider the hash assignment code broken? If you need to call a function in scalar context, make it explicit.


Comment on Re^3: Module Announcement: Perl-Critic-1.01 (just a scalar)
Re^4: Module Announcement: Perl-Critic-1.01 (just a scalar)
by jettero (Monsignor) on Jan 26, 2007 at 22:11 UTC
    Why make (key => scalar &functionScalar) explicit, but not return undef;? That sounds like a matter of personal preference to me.

    -Paul

      Because it's the calling context that matters!

      Bare return; does the right thing in both scalar and list contexts. In my mind, that's a good thing.

      If you find yourself in an ambiguous situation, then you disambigate by being explicit. It would be nice if there were never ambiguous code, but that's not realistic.

        Bare return; does the right thing in both scalar and list contexts.

        I'm assuming that you are defining "the right thing" as "being false". For many functions, the "right thing" even in a list context is "return one scalar". Next we'll replace NaN with an empty list for the math functions.

        If you aren't assigning the list (return value), then the boolean nature of what is returned doesn't matter (well, if you are just checking the return value, then you aren't in a list context and return undef; works fine). Do you find yourself writing a lot of code where you assign a single scalar to an array and want to test that assignment in a boolean context? I don't, and I think there are good reasons why I don't.

        Do you find yourself constructing lists from several scalar expressions where the size of the resulting list should not change? I do. Quite a bit, actually. It is a natural thing to do in Perl. So things that return a scalar should return a scalar.

        Doing the "right thing" in a case that matters and is natural is much more important to me than doing the "right thing" in a case that I find doesn't matter (because it is unnatural).

        - tye        

Re^4: Module Announcement: Perl-Critic-1.01 (scalar)
by tye (Cardinal) on Jan 26, 2007 at 22:45 UTC

    Do you write the following?

    my %hash= ( key1 => scalar lc $value );

    If not, then it is probably because you know that 'lc' just returns a scalar. If you do, then there are probably a lot of people who find you silly. 'lc' isn't the only function I use that just returns scalars. Sprinkling 'scalar' all over hellenbach doesn't improve code much in my experience.

    I actually consider the => to be broken for not enforcing scalar context on both sides. But that still just shifts the problem to things like function arguments.

    Now, there are places where using scalar() is more appropriate. But, no, I don't consider using it on a function that just returns a scalar to be such a place. And I don't think transforming every function that might want to return an undefined scalar into "a function that returns a scalar except when it wants to return a undefined scalar in which case it returns an empty list instead and if you really wanted the undefined scalar then you should wrap the call in scalar() for that purpose" to be even close to an improvement strategy.

    - tye        

      Your position is problematic because your model ignores a fundamental, from perlsub: The Perl model for function ... return values is simple: ... all functions ... return to their caller one single flat list of scalars.

      lc doesn't return a scalar it returns a one element list.

      Be well,
      rir

        That statement doesn't contradict my position. I never said that a single scalar can't also be considered as a list. I'm not playing some semantic game. I'm talking about practical implications.

        If we want to play your semantic game, then replace "scalar" with "single-item list" throughout what I wrote (which requires patching Perl to rename the scalar() function, but such is life).

        If you have a function that always returns exactly one item (as the list of items that it returns), then it doesn't make sense to change this function to return a zero-item list in one special case. (Why? Read what I wrote above.)

        lc doesn't return a scalar

        Repeat that to a few random people who know Perl and see how silly this particular semantic argument is. lc() always returns just a scalar. The list of scalars that lc() returns always has a size of one. Those are both true. *shrug*

        - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://596796]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (19)
As of 2014-10-22 15:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (119 votes), past polls