Front page | perl.perl5.porters |
Postings from July 2011
* 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? :-)
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. 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.
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, when the de-facto default semantics for the equivalent
operation has been a different one forever and is perfectly
serviceable. (I would argue it is *better* than ROness, but that
is merely my belief. Practice hasn’t borne that out; the above,
it has.)
Why would you intentionally change two things at once together?
If one of them turns out to be a mistake do you *want* to live
with the perennial choice of either accepting the misfeature in
order to get the good feature or missing the good feature in
order to avoid the misfeature?
> >> 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, and that’s what
you’re then mutating. If you want it read-only then make it
read-only.
But it’s half comical and half embarrassing to have to write
say ++$_ for my @copy = (1,2,3);
instead of just
say ++$_ for 1,2,3;
The latter should just work.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next