develooper Front page | perl.perl5.porters | Postings from July 2011

Re: Why views are useful, and why their syntax doesn't matter much

Thread Previous | Thread Next
Reverend Chip
July 15, 2011 16:15
Re: Why views are useful, and why their syntax doesn't matter much
Message ID:
On 7/15/2011 2:36 PM, Aristotle Pagaltzis wrote:
> * Reverend Chip <> [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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About