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

Re: Re: OO Getters/Setters

by boo_radley (Parson)
on Dec 31, 2003 at 20:48 UTC ( #318007=note: print w/ replies, xml ) Need Help??


in reply to Re: OO Getters/Setters
in thread OO Getters/Setters

$self->foo(123) # chaining of mutator calls ->bar(456);
this always gave me the heebies because returning the object for success seems a little fragile. What if ->foo() fails? Is it still sensible to return the object? What happens if you have a mutator (well, a not-mutator according to hardburn) that rejects the data presented for whatever reason? If your mutator returns an error code because ->foo(123) is bad input, you wind up with, i.e., "123 is an invalid foo"->bar(456) and your code goes pear-shaped.

Sure, maybe "123 is an invalid foo" is up for argument as a sensible error code. The point is that it seems like a way to limit your object if you need to do any interesting things to communicate failure to back to your user.


Comment on Re: Re: OO Getters/Setters
Select or Download Code
Replies are listed 'Best First'.
Re: Re: Re: OO Getters/Setters
by stvn (Monsignor) on Jan 01, 2004 at 01:59 UTC
    this always gave me the heebies because returning the object for success seems a little fragile.

    I couldn't agree more, and not only is returning the object fragile, but the whole idea of an accessor and a mutator (getter and setter) rolled into one subroutine seemed to be to be just a opening for interface confusion. What if i want to provide an accessor, but not a mutator. Now convention is broken, and programmer assumptions are thrown out the window. While 'getField' and 'setField' are tedious to code initially, they have a tendency to pay off in terms of maintainability and ease of understanding for others.

    What if ->foo() fails? Is it still sensible to return the object? What happens if you have a mutator (well, anot-mutator according to hardburn) that rejects the data presented for whatever reason? If your mutator returns an error code because ->foo(123) is bad input, you wind up with, i.e., "123 is an invalid foo"->bar(456) and your code goes pear-shaped.

    I would argue here though that if '->foo()' fails, then you should throw an exception, and not return an error code. In which case the method chaining doesn't matter, since you would've longjump-ed outta there already.

    -stvn

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (11)
As of 2015-07-29 07:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (261 votes), past polls