[sf-perl] Fwd: Delivery Status Notification (Failure)

Joseph Brenner doomvox at gmail.com
Tue Oct 1 13:38:08 PDT 2013


> Should look at Obejct::IndsideOut one of these days.)

The inside-out object fad seems to have cooled quite a bit.   Objects with
perfect encapsulation sound like a good idea at first, until you realize
that you can't debug them by just doing a

   print Dumper( $obj );

The Moose-heads seem to be winning the day, though party because there are
lighter-weight workalikes around like Mouse and Moo.







On Tue, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131001/74ed7d18/attachment-0001.html>


More information about the SanFrancisco-pm mailing list