Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??
First of all I want to point out that my reply to which demerphq replied should be read in its right context: as a reply to a question about wantarray and proper usage.

Funny. There a number of situations where ive taken advantage of this very feature [passing extra arguments].

There's a big difference between seeing where you can take advantage and have a desire to take that advantage. I can see when you might want to do it, but I've never felt I actually want to do it. When you do it it's quite likely that you've written your dispatch routines yourself. And if that's the case then I see no problem with it. You've hopefully documented that extra arguments will be ignored and that it's safe to do that.

However, when I use such techniques myself I've found that I do it mainly when the routines takes the same arguments. Sometimes the routines are generalized to ignore some arguments though, just to fit into the template. But they're almost always related. But even if they're not, I'm not all convinced it in the general case it A-OK to pass extra arguments. I'm not into too much stricture, so I wouldn't disallow it. But I hope that the programmer doing it is aware of that it can lead to bugs in the future, like when a module is updated. Module authors expect their users to follow the manual. I wouldn't hesitate a second to add an extra argument to a subroutine if I had documented the subroutine to take a specific number of arguments. But whilst I'm against excessive stricture I still want to help the programmer discover his error. If I see a great potential for a user to error I consider putting in a warning. In my argumentation to which you replied, that is the case. There is a great chance that if the warning is issued something unforeseen or unintended happened in the user's code.

When calling the overriden sub its fairly natural say something like sub blah { $foo->SUPER::blah(@_); ... }

This does not relate much to my post, as far as I can see. But this is not an obvious issue, as I understand it, and could be the topic of another discussion.

So IMO warning when someone passes too many parameters seems a little extreme.

I can't see where I've advocated this. I've recommended programmers to use the same philosophy as Perl itself does when it comes to warnings. For instance, @foo = $bar, $baz gives a warning in void context, because most likely the programmer didn't intend it to be (@foo = $baz), $baz. I'm saying the same here: Warn if it looks like the programmer did something he didn't want to, but also give a way to disambiguate and get rid of the warning. In my case above, that simply means you make a list assignment instead of a scalar assignment.

# Consider a subroutine with a 1-to-1 # argument to return length mapping. my ($a) = foo($bar); # OK my $a = foo($bar); # OK my ($a) = foo($bar, $baz); # OK my $a = foo($bar, $baz); # Warns. # Why did the programmer pass two arguments # if he just wanted one return value?

In real life it could look like this:

  my $a = foo(burk());

and &burk is believed to return just one element. Perhaps the user was wrong in that, and &burk returned more than one element. Or perhaps &burk needed to be called in scalar context to give the expected return behaviour of one element, like localtime(). If I'm reading you right, you would be annoyed by that it warns?

I also would like to extra clearly point out that I wasn't talking about arguments length checks per se. I was talking about return list length. Checking against @_ is just a way to in a simple way often be able to check the return length. Again, my statements in my reply must be read in its proper context. I was talking about my &get_headers method, that uses one-to-one argument to return length mapping. If you read my rule of thumb (which is just that; a rule of thumb and thus has exceptions) again you'll see that it's generalized to be about the output rather than the input. That ought to be clear in the code illustration.

If you do that then I at least hope that you use warnings::register;

Or I use a global like $Pkg::WARN so pre-perl5.6 programmers can control the warnings. Or a combination of the two. The functionality warnings::register gives you (described in perllexwarn for those that are unfamiliar with it), is unfortunately not so well known, nor used. I think it should be given more attention.

... so that I can turn off the annoying messages instead of having to write tortured code just so your sub gets the correct number of parameters.

Or you could just disambiguate... don't torture yourself when you don't have to.

Me: I'm especially paranoid against other programmers
You: Im sympathetic to this postion, but I think its a fine line between being paranoid, and being unduely restrictive.

I'm not saying that I'm paranoid against my users. I'm not afraid of their abuse of my code. I'm paranoid when I am the user. I choose to write my code to be restricted by the documentation of the module I'm using. If the documentation says the subroutine wants three arguments, then it gets three arguments. If I break this deal between me and the module author I have no one to blame but myself. So I do as the documentation tells me.

If the end user wants to give you more arguments then you need, then theres a decent chance that decision was a sound one.

Not in this case! It's most probably a slip-up, and I want to be fair and warn the user. See the example above.

I certainly disagree with code that makes it impossible to do something just because the author couldnt see any reason why anyone would want to do it. (A position that you arent necessarily advocating I realize, but you can see the relevance I hope.)

I sure don't advocate that. I don't see the relevance, but I trust you that there is. But while on the topic I can just as well elaborate a bit. Why I definately not am advocating this is because I believe some of my users to be smart--often a lot smarter than I. So they might come up with cool tricks that follow by the unrestrictive interface. And I want to let people be creative. Sometimes though, restriction can be accepted. One of those cases are when you see potential future constructions that might necessarily restrain certain things. It's better to start restrictive in such cases, and easy up the rules later on. If users are significantly disturbed by my restrictions they'll hopefully let me know. If they come with good arguments, I'll sure consider it. But I don't want to paint myself in a corner due to premature design. (CPAN has examples of this.) Some modules need a couple of releases to grow, and initially you want to keep your doors open. I much prefer this over having the whole module marked as experimental, since that probably leads to that the people who actually want/need to use it in real-life situations won't, and I won't get the feedback I need on it.

ihb

In reply to Re: Re: Re: Context aware functions - best practices? by ihb
in thread Context aware functions - best practices? by Aristotle

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others drinking their drinks and smoking their pipes about the Monastery: (8)
    As of 2014-12-18 06:41 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      Is guessing a good strategy for surviving in the IT business?





      Results (43 votes), past polls