Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Re: OO Getters/Setters

by boo_radley (Parson)
on Dec 31, 2003 at 20:48 UTC ( [id://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.

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
Domain Nodelet?
Node Status?
node history
Node Type: note [id://318007]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-03-28 14:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found