Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
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.

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?
[Discipulus]: oh thanks, i'm always at well as the ratchet or bucket
[Corion]: But I'm slowly starting to get into programming again - yesterday I translated my talk for YAPC::E (in Amsterdam) to English, and decided to put my Jekyll-clone to rest for the time being
[Corion]: Discipulus++ # being well is like being earnest
[marto]: hopefully next year I'll be in a position to go to Perly things in Europe :)
[Corion]: Maybe I'll use the Real Jekyll a bit to get a feel for how it actually works, and to get annoyed by it ;)
[Corion]: marto: That would be cool :) There is no kids care at Perly events unfortunately, so it's not entirely family friendly
[Corion]: I think I should define a set of (say) five projects through which I rotate from time to time, just to prevent myself from being bored/annoyed by the problems they get stuck in ;)
[marto]: Corion, not bringing the kids would make it ideal :P
[marto]: a suggestion, have one project in the list that isn't programming/perl related
[Corion]: marto: Yeah, things are more parent-friendly the way they are ;))

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2017-07-27 07:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I came, I saw, I ...
























    Results (404 votes). Check out past polls.