[sf-perl] Fwd: Delivery Status Notification (Failure)
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.
> 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
> > 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
> > 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
> > (yup, that's convenient all right).
> > But then, where I work at present, most of the code just accesses the
> > 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
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SanFrancisco-pm