Front page | perl.perl5.porters |
Postings from July 2011
On 7/13/2011 5:35 PM, Aristotle Pagaltzis wrote:
> * Reverend Chip <rev.chip@gmail.com> [2011-07-13 23:50]:
>> On 7/11/2011 6:38 AM, Aristotle Pagaltzis wrote:
>>> * Reverend Chip <rev.chip@gmail.com> [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 Readonly.pm, 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