Front page | perl.perl5.porters |
Postings from July 2011
* Reverend Chip <rev.chip@gmail.com> [2011-07-14 06:25]:
> On 7/13/2011 5:35 PM, Aristotle Pagaltzis wrote:
> > The one time I used locked hashes was as a clever hack for
> > some kind of set intersection. I don’t see anybody else using
> > them for very much of anything either.
>
> I like them a lot; they're an obvious outgrowth of C<use
> strict> because there's no point in typo checking "$a" but not
> "$a->{b}".
Locked hashes throw exceptions at runtime. Stricture violations
blow up at compile time. Those are very different kinds of
safety. If you want real typo checking on that level, you need
inside-out objects. (If you write `$a->{'b'}` as `$b{ $a }` then
than is wholly strict-checked.)
> IMO, it's obvious that Moose constructors should lock every
> object's hash after construction (by default at least).
> Otherwise there is no detection of attribute typos. Hm,
> I should write a MooseX for that.
And what do subclasses (and roles) do?
> *If* we can make COW pervasive enough that we're not giving up
> efficiency on every function call... Sure, I can live with
> that.
For almost two decades we have accepted the slowness implicitly
by using the de-facto idiom. If it no one cared that much so far,
how come it is such a make-or-break concern now?
Don’t get me wrong, I am all for any optimisation possible, but
it I would prefer the importance of performance to be judged
accurately when we let it affect semantics; and real-word
experience on this one says what we had before was adequate.
(In fact making CoW more pervasive will benefit performance of
code beyond parameter passing, too.)
> > Why would you intentionally change two things at once
> > together?
>
> A combination of speed and safety is no small benefit. That is
> the motivation. COW *might* provide that, but I didn't think of
> COW at first. And even now I'm not entirely sure it will be
> enough. I'm willing to try tho.
I’m unconvinced that making things read-only is a substantial
increase in safety over making copies of them. I suspect it would
be substantially less convenient, but I can’t argue that from any
experience.
> > If you write ++${\10} that should yield 11 no matter how
> > often you evaluate it. You should get a copy (or rather, via
> > CoW, a potential copy) when you evaluate a constant....
>
> I appreciate the purity & consistency of this position, but
> I'm not fond of it, because I foresee it costing a lot of
> performance for absolutely no practical gain. Its only payoff
> is ideological bragging rights, which don't motivate me.
The pay-off is convenience and lack of surprises in a variety of
edge cases. I am motivated by run-ins with them in practice, not
by purity.
And if you’ll allow me to remark, unfounded claims about safety
seem far more the territory of ideology and bragging rights to
me. :-)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next