[sf-perl] Delivery Status Notification (Failure)

[Maxim Yemelyanov]

We're using Class::Accessor, hence we have

$value = $foo->thing;
$foo->thing($value);

which clearly differentiates the set/get syntax.

- Max


On Tue, Oct 1, 2013 at 9:41 AM, Michael Friedman <frimicc at gmail.com> wrote:

> 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.
> > -y
> >
> >
> > 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)
> >>>
> >>>
> http://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects/where
> >>> 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
> >>> I’ve
> >>> seen uses that naming scheme. The naming of writers matters less if
> >>> they’re
> >>> 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
> >>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> >>>
> >>
> >>
> >> _______________________________________________
> >> SanFrancisco-pm mailing list
> >> SanFrancisco-pm at pm.org
> >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> >>
> > _______________________________________________
> > SanFrancisco-pm mailing list
> > SanFrancisco-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131001/7c3abb1c/attachment.html>