[sf-perl] Delivery Status Notification (Failure)
frimicc at gmail.com
Tue Oct 1 09:41:04 PDT 2013
I agree with both of these opinions. In my last job, we had explicit get_title() and set_title() methods, but what we found was that we hardly ever called the set methods -- the values were almost always set when we got the item out of the DB. So optimizing for the get is a much better approach.
In my current job, we don't do much OO Perl, but when we do we leave the get methods as just field name, title(), and make the set methods have some other name. We don't usually use set_title(), though, because we're setting it a particular way. set_title_from_feed() or set_title_from_clip() and so on, so that we can encapsulate different data-prep behaviors and have the function names be self-documenting.
-- Mike Friedman
On Oct 1, 2013, at 7:26 AM, yary <not.com at gmail.com> wrote:
> Been a while since I've done OO perl, but the last time I did on one
> of my personal projects, I used separate getters/setters- can't
> remember which format. (As for directly accessing href's, I'm
> heretical and often use array-refs when rolling my own objects, with
> "use constant" for field names. Only makes sense when your object has
> a mostly-fixed set of fields. Should look at Obejct::IndsideOut one of
> these days.)
> I suspect the common use of same setter-getter is due to it being the
> default for many modules (like Moose), and not from thoughtful choice!
> And I'd also think those modules were influenced by languages that
> have function signatures; languages where having the same name for
> getter-setter doesn't mean they call the same function because the
> arguments- or lack of- change which gets called.
> On Mon, Sep 30, 2013 at 9:20 PM, Joseph Brenner <doomvox at gmail.com> wrote:
>> I've always agreed with Rolsky: the getter form is far more common, so you
>> should optimize for that.
>> And I've always agreed with Conway that separate setters and getters were a
>> better idea than "mutators", where you use an undef argument to indicate
>> when you want to just do a get.
>> As far as I can tell, pretty much no one agrees with this, they much prefer
>> the "convenience" of the short form that does both functions... and they
>> tend to add additional methods in order to clear a field and set it to undef
>> (yup, that's convenient all right).
>> But then, where I work at present, most of the code just accesses the href
>> directly, which I gather is common at many places (e.g. Yahoo) and I
>> wouldn't swear that this is the wrong thing to do: there are decent
>> arguments against it, but they're not as strong as some people pretend.
>> For example: if you use accessors religiously, you then have the power to
>> write funny accessors that slip in magical behavior when someone tries to do
>> a simple get or set... but I find that when I do that, I tend to confuse
>> myself later: there's some odd code buried in a place where I normally
>> wouldn't look for it.
>> On Mon, Sep 30, 2013 at 3:55 PM, Kevin Goess <cpan at goess.org> wrote:
>>> Back in 2005 Damien wrote his now-famous Perl Best Practices, and
>>> recommended separate get_ and set_ methods for accessors.
>>> I just now noticed a post by Dave Rolsky (himself no lightweight)
>>> he opines:
>>> Damian wants you to write get_name() and set_name(). I don’t think this
>>> ever took off. My personal preference is name() and set_name(), though
>>> that’s just as unpopular.
>>> I think the real recommendation should be to use read-only attributes as
>>> much as possible. Mutability adds complexity to your code. Avoid it
>>> whenever possible.
>>> In that context, I’d avoid the get_name() style. Very little Perl code
>>> seen uses that naming scheme. The naming of writers matters less if
>>> rare, but readers will be common, and you should just use the style that
>>> everyone else uses.
>>> I've also rarely seen that naming scheme (and don't use it myself), but
>>> haven't done an exhaustive survey.
>>> Does anyone else have a sense on how widespread the take-up of that
>>> particular Best Practice has been?
>>> SanFrancisco-pm mailing list
>>> SanFrancisco-pm at pm.org
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
More information about the SanFrancisco-pm