Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: OO design: returning string and/or special value

by 1nickt (Canon)
on Oct 07, 2019 at 21:25 UTC ( [id://11107166]=note: print w/replies, xml ) Need Help??


in reply to OO design: returning string and/or special value

Hi, if you don't want to require the caller of your method to provide params (?!) you should just return all the data and let the caller consume the parts that are interesting. Return a hashref if the caller is another Perl routine, or a JSON obj if there's data interchange. Steer clear of wantarray and conditional/inconsistent return values in general.

Hope this helps.


The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^2: OO design: returning string and/or special value
by wanna_code_perl (Friar) on Oct 07, 2019 at 22:14 UTC

    I'm trying to go with the good old Larry Wall-ism and "make the easy things easy, and the hard things possible". I need the basic string representation 95% of the time, so making the caller remember to write $obj->method->{string} (hashref) or $obj->method->string (object return) or similar is the sort of thing I'm trying to steer away from if reasonably possible.

    I grant you wantarray can occasionally be mildly surprising in certain edge cases, but I disagree that one should always steer clear of it. In my particular case I don't see how different contexts would confuse an average Perl programmer to any significant degree, even if they don't RTFM. If you want to explain your objection to wantarray in this case, though, I'd be grateful for another perspective on that! See my reply to stevieb for some example code.

    if you don't want to require the caller of your method to provide params (?!)

    What's surprising about a method without params? Or were you just emphatically confirming whether my method did or did not require params? (It doesn't).

      Nothing surprising about a method that does not take params, if the method always returns the same thing. For a method that does not always return the same thing (not a good idea anyway), not providing a way for the caller to specify what is wanted via a param seems solidly in the realm of misplaced optimization.

      You asked for suggestions on how to design for your need. My experience has shown me that clarity, simplicity and consistency are above all. So I shared my suggestion. I'm not interested in debating things like "should I have a type constraint that only warns on a bad value" or "should I have a method return one of three things but take no parameters," to be honest. Those questions are long settled, in my view. While TIMTOWTDI is still true, there's usually a standard way to do most basic programming tasks in Perl, these days, or at least some standard ways to *not* do them.


      The way forward always starts with a minimal test.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (7)
As of 2024-03-29 08:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found