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
Aristotle Pagaltzis
July 13, 2011 17:35
Re: Why views are useful, and why their syntax doesn't matter much
Message ID:
* 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? :-)

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

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.

Aristotle Pagaltzis // <>

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