develooper Front page | perl.perl5.porters | Postings from March 2023

Re: refaliasing disrespects readonlyness of array or hash

Thread Previous | Thread Next
From:
Zefram via perl5-porters
Date:
March 20, 2023 18:59
Subject:
Re: refaliasing disrespects readonlyness of array or hash
Message ID:
ZBis4fQuhYMG9NNL@fysh.org
demerphq wrote:
>At least in this case you are wrong. Marking a hash as readonly does not
>make its values readonly.

I didn't try to write to its value scalars.  I was altering which
scalars it references, which is (part of) what the readonly flag is
meant to prevent.

>          You can delete keys that it contained, or modify them.

If you look at my test case, you'll see that deleting an element, with
the "delete" operator, *is* prevented.

>                                                  If you want to mark a
>value in a hash as readonly you must explictly mark *that* variable as
>readonly.

I'm well aware of the distinction.  Marking a value scalar as readonly
is not relevant to the test.  If you want to try it, though, insert
"SetReadOnly(\$a{bb});" into the test case, and you'll see that that
also doesn't prevent the refaliasing operation.

I'm also aware that there's more to a restricted hash than readonlyness,
but the additional semantics don't seem relevant here.

>Internals::SetReadOnly is not a documented function,

Ah, this is confusing.  What we have here is a collision between the
Internals module on CPAN and the builtin functions that the Perl core
puts into the Internals package.  Internals::SetReadOnly() is from the
CPAN module, and it very much *is* documented in that module's POD, and
is in its @EXPORT_OK list.  Whereas Internals::SvREADONLY() is supplied
by the core, and is neither documented in Internals.pm nor in @EXPORT_OK.

>            and even then you conflating "container" and contents in this
>part of your bug report.

No, I'm really not.

>                                                              making it
>even harder for us

It's harder to handle when correctly labelled?  That is a surprising
finding.  If there's a consensus that the correct labelling is
counterproductive then sure, we can do it with incorrect labelling.

>                   is just over the top.

You write here as if I'm deliberately making things difficult.  I'm not.
The recent bug reports in Markdown form are partly experimental, testing
the handling of Markdown in email.  I did not know what the outcome
would be.  I did not anticipate that the MIME labelling would actually
cause a problem, but that's the sort of thing that the experiment is
meant to discover.  It also wasn't my idea in the first place to write
bug reports in Markdown.

>                     i do mind that you refuse to work with me to make it
>easy.

I'm not clear what kind of working with you to make it easy was missing
here.  I don't recall you objecting in advance to the suggestion about
MIME headers.  It seems to me that the appropriate next step in working
together on this was in fact to try out what had been suggested to see
how well it works, which is what has just happened.

>                       refusing to sign up and use it to interact with the
>rest of us who use it as the main way to manage perl is just anti-social.

If you want to say that non-GitHubbers should just go away, say it.

-zefram

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About