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 13, 2011 21:20
Re: Why views are useful, and why their syntax doesn't matter much
Message ID:
On 7/13/2011 5:35 PM, Aristotle Pagaltzis wrote:
> * Reverend Chip <> [2011-07-13 23:50]:
>> On 7/11/2011 6:38 AM, Aristotle Pagaltzis wrote:
>>> * Reverend Chip <> [2011-07-11 04:05]:
>>>> On 7/10/2011 5:15 PM, Father Chrysostomos wrote:
>>>>> I can’t speak for Perl 6, but making something read-only in
>>>>> Perl 5 just feels un-Perl-5-ish.
>>>> Perl 5 has to evolve
>>> But when is that an actual necessity, and when is it merely
>>> an excuse for muddling through without careful thought?
>> In the end these are matters of intuition and judgment. My
>> judgment is that Perl does not consist entirely of mutable
>> things; only mostly. Or would you like to revoke the idea of
>> locked hashes? Would your preferred dialect of Perl not even
>> have SvREADONLY?
> Is that the best you could come up with? :-)

In the end, we all have our own internal versions of Rules #1 and #2.

> 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}".  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.

>  From what recollections about their
> motivation I still have, they are merely another failed object
> system. I don’t care if they stay or go and I don’t think their
> presence sets a precedent for anything.

We'll have to agree to disagree on this one.

> As for SvREADONLY I explicitly said people can should use that
> (in the form of, say) if they want to and I have no
> objection against providing some level of syntactic sugar to make
> it easier. I just don’t agree with pushing it as a default for
> syntax that is not only supposed but destined to become the new
> Right Way....

Point taken.

> , when the de-facto default semantics for the equivalent
> operation has been a different one forever and is perfectly
> serviceable.

*If* we can make COW pervasive enough that we're not giving up
efficiency on every function call...  Sure, I can live with that.

> 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.

>>>> and Perl 5 has always had some read-only things. Or are you
>>>> suggesting that   ${\3.14159}   should be mutable?  :)
>>> Yes it should be. It isn’t now, because that would mutate the
>>> value in the optree, but that’s exposing an implementation
>>> detail...
>> I'm afraid we'll have to disagree about that. "Variables don't,
>> constants aren't" is supposed to be a joke, not a design
>> principle.
> Give me a little more credit here. If I were joking it would’ve
> been funny. :-) It wasn’t and I wasn’t: I never said the constant
> should be mutable.
> 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.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About