Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

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

by wanna_code_perl (Friar)
on Oct 07, 2019 at 22:14 UTC ( [id://11107170]=note: print w/replies, xml ) Need Help??


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

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).

Replies are listed 'Best First'.
Re^3: OO design: returning string and/or special value
by 1nickt (Canon) on Oct 08, 2019 at 00:13 UTC

    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://11107170]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (5)
As of 2024-04-19 13:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found