[sf-perl] Delivery Status Notification (Failure)

Tue Oct 1 13:47:47 PDT 2013

> We're using Class::Accessor, hence we have
>
> $value = $foo->thing;
> $foo->thing($value);

And what do you do if $value is undef?

  if( defined( $value ) ) {
    $foo->thing( $value );
  } else {
    $foo->clear_thing;
  }

But I see Class::Accessor these days has hacks built-in to follow Damien's
"Best Practices" if you like, or alternately to mimic Moose behavior.

On Tue, Oct 1, 2013 at 12:35 PM, Maxim Yemelyanov <maxim4d at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/d4ecf37c/attachment.html>