Front page | perl.perl5.porters |
Postings from March 2023
Re: refaliasing disrespects readonlyness of array or hash
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 25, 2023 20:22
Subject:
Re: refaliasing disrespects readonlyness of array or hash
Message ID:
CANgJU+XQUXJPjR5HR=quCkkf3Ks9ra5GKZr6RX8Z8zv7Ak5pWA@mail.gmail.com
On Sat, 25 Mar 2023 at 20:37, Zefram via perl5-porters
<perl5-porters@perl.org> wrote:
>
> demerphq wrote:
> >I dont see a problem here. The local is ending and we are putting it
> >back to the original state.
>
> The state immediately before the end of the local scope is a restricted
> hash, which appears to preclude replacing that key. One can't make that
> change in the ordinary way, and so I reckon the restoration via local
> should also be unable to make that change. local restoration doesn't
> have a general exemption from the language semantics.
I don't agree. We can do what we want with restricted hashes, and the
logical thing for this case is to allow local to undo whatever change
was made to the value since the localization, just like local undoes
any other change to a value.
>
> If local restoration is exempt from immutability (indeed, if anything is
> semantically exempt from immutability) then that destroys the usefulness
> of immutability.
That is the fallacy of the excluded middle. You are welcome to your
opinion, but I don't see any contradiction.
These are /restricted hashes/. You are imputing that restricted hashes
are immutable in a way that hasn't been agreed on. You already said
you don't understand restricted hashes, and now you are taking the
most extreme interpretation of what they mean. IMO that is not
reasonable.
> It would be impossible to rely on readonly values not
> changing, and that's a really useful thing to rely on. In practice, of
> course, people would just rely on them not changing anyway, and get burned
> when they actually change. It's a formula for widespread subtle bugs.
Sorry, I don't agree. I think it is an extreme interpretation that is
unnecessary to take. A key in a restricted hash is mutable until
marked as readonly. If someone localizes a mutable key, and marks the
localized version as readonly, that does not preclude the localization
ending, it merely precludes that anyone can modify that now readonly
key until they turn off the readonly flag, or the localization ends.
So for instance it precludes the localized item being localized again,
but that doesn't mean it should undo the localization. I can entirely
imagine someone localizing the key *because* they are going to mark it
readonly, and want to be sure that it gets restored to mutable if
there is an exception in their logic. That sounds like a much more
reasonable behavior than what you are suggesting.
Restricted hashes are designed to have their values readonlyness
change dynamically. It is part of the API. All we are saying is that
when they are delocalized they return to their previous state of
unlocked. (After all you can only localize an unlocked key.)
> If you really want local restoration to be exempt, though, then this is
> a bug (still present in your branch):
>
> $ perl -lwe '%a = qw(aa bb cc dd); { delete local $a{aa}; Internals::SvREADONLY(%a, 1); print %a; } print %a'
> ccdd
> Attempt to access disallowed key 'aa' in a restricted hash at -e line 1.
That looks like a "don't do that" bug to me. if you lock a hash after
localizing its keys you get to keep the exception that it triggers. We
can simply document "don't do that". And considering it does trigger
an exception you can be sure nobody is doing it. Ideally we could
check and see if a hash had any localized members and refuse to mark
it as restricted if it did, but that is probably infeasible so we
should just tell people "don't do that".
> > I think they are basically a failed experiment,
> >except that every time I say that someone pops up and says "but I like
> >them". :-(
>
> I'd like to introduce straightforward read-only hashes. It shouldn't be
> much work. To coexist alongside restricted hashes we'd need one extra
> flag on HVs saying which kind of read-only it is if it's SvREADONLY.
I am curious what you mean by that. I have implemented protected
hashes in #20928, but they are pretty much the same as restricted
hashes with the caveat that they dont throw an exception when someone
reads a key that does not exist.
> > and IMO if we did consider it illegal it would be
> >pretty confusing,
>
> Isn't it more confusing to have a read-only object change its value?
No, not really. With restricted hashes the notion that a value or the
entire hash might change from "readonly" to "mutable" during process
lifetime is part of the API. That it happens when the localization is
undone is pretty reasonable. Its no different from the value changing
from "a" to "b".
> > given a read-only value is not allowed to be updated or deleted,
> >it also shouldn't be allowed to be localized.
>
> I disagree. If local restoration is allowed to alter the state of a
> read-only object then I reckon it's equally legitimate for the forward
> side of localisation to change it.
Well, I think it is consistent and i think its what most people
familiar with restricted hashes would expect.
I start off with a hash with unrestricted values but restricted keys,
i localize one of the unrestricted keys, I expect when that
localization is undone for the localization to be undone /whatever
happened to value/. If I lock one of the keys, i then expect that it
cant be localized or otherwise changed until it is unlocked. If i
lock a key that was localized then when it gets unlocalized it gets
unlocked. Seems pretty straight forward, consistent with established
norms and reasonable to me.
> It's not making a change to the
> object in the dynamic scope where it had that read-only state; it's just
> temporarily hiding that state. I don't think that allowing localisation
> to affect read-only objects makes for good semantics, but at least it
> would be consistent semantics if dynamic scope boundary crossings were
> free to do this in both directions.
I don't agree. I think if you showed sample code implementing the
simple interpretation I propose to most Perl hackers they would
consider it pretty reasonable (at least from the point of view of how
restricted hashes already behave).
There is no reason that consistency is required between localization
and delocalization. You seem fixated on that without any good reason,
and your personal definition of "consistency" isn't a good reason IMO.
I think "consistency with how local works generally" is more important
than "consistency with how locked hashes work when the key is locked".
After all the local came first historically, and (assuming my patches
are applied) it came first imperatively in any program as you can't
localize a locked key.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next