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. -zeframThread Previous | Thread Next