Front page | perl.perl5.porters |
Postings from July 2011
On 7/15/2011 2:36 PM, Aristotle Pagaltzis wrote:
> * 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.
Some do, some don't. C<use strict 'refs'> doesn't. And of course would
*love* to have compile time member typo exceptions. In fact I proposed
to Larry long ago that every object should have a PAD, and inside a
method $attribute should be a lexical. He didn't buy it. Maybe I
should bring that back... Meanwhile, well, we make do with what we have.
>> 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?
Only the final class knows the attribute list, so only the final class
can lock the hash.
I uploaded a module to do it. MooseX::Locked. Share & Enjoy!
>> *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?
Come now, just because an acknowledged, embarrassing problem has been
tolerabled for a long time doesn't mean addressing it is a waste of
time. If this is seriously one of your arguments, you're just
marginalizing yourself. You may as well argue against the Internet or
indoor plumbing.
> 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.)
Quite true.
>
>>> 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.
I've been coding Perl for 20 years and I have yet to find immutable
constants inconvenient or surprising, nor have I heard any significant
complaints about them being inconvenient or surprising. I don't doubt
your sincerity, but you're really not achieving persuasion.
> And if you’ll allow me to remark, unfounded claims about safety
> seem far more the territory of ideology and bragging rights to
> me. :-)
Compared to non-readonly aliasing, readonly aliasing is unquestionably
safer. The whole "unfounded" thing is, again, baseless.
/bozo bit on standby
Thread Previous
|
Thread Next