Front page | perl.perl5.porters |
Postings from March 2023
Re: Pre-RFC Deep constants
Thread Previous
|
Thread Next
From:
Matthew Persico
Date:
March 11, 2023 14:20
Subject:
Re: Pre-RFC Deep constants
Message ID:
CAL20dLAQUGmsAVtP40Vwx4LTj0-o3u3ZiZnVGYrKaoWMaMqPPQ@mail.gmail.com
How about an MVP that creates just scalar constants? That's got to be 90%
of what people need, and then we can add constant hashes later? After all,
constant hashes are just a bunch of constants for those of us with
namespace OCD (including myself!).
Or maybe we agree that constant hashes can only have scalar, non reference
values?
On Fri, Mar 10, 2023 at 11:11â¯AM Martijn Lievaart <m@rtij.nl> wrote:
> Op 10-03-2023 om 07:28 schreef Branislav ZahradnÃk:
>
>
>
>> Don't by confused by simplicity of examples, eg:
>> my @structs = ({ ... }, { ... }, ...);
>> my $var : const = [ @structs ];
>>
>>
>> That copies the contents of @structs, after which the same rules apply.
>> If your point is that @structs uses { ... }, which is a reference, that
>> obviously should count as a const reference. That would be the same as
>>
>
>> my $var : const = [ { ... }, { ... }, ... ];
>>
>>
>> If that is not what you are saying, I don't get the point.
>>
>>
> Oh, I missed your idea was to always do deep copy. That may work in few
> use cases, though it may be unnecessary expensive.
>
>
> Ah, now I see. So if you do:
>
> my @structs = ({ ... }, { ... }, ...);
> my $var : const = [ @structs ];
> $structs[1]->{something}='blah';
>
>
> That would change the underlying data structure referenced by $var. Which
> to me is both non intuitive, and asking for subtle bugs. I'ld say, either
> forbid references, or better, allow them only if we are the only one
> holding a reference (can we know that?).
>
>
> On the other hand, Using references in this way can be said to be a case
> of bullet and foot. Documenting that careless use of references can averse
> affect "deep-constness" is indeed also an option.
>
>
> Though still doesn't use case "for me data are read-only, for everyone
> else data are read-only / write-once".
>
> Thinking about it, there are multiple modes:
> - const ... value cannot be modified, never
> - read-only ... value is read-only in current context, though it can
> modified in another context
> - read-write ... value can be changed
>
>
> As you state here, const is unchanging. It's unintuitive if it can still
> change, that fits the description of read-only (but see above).
>
>
> HTH,
>
> M4
>
--
Matthew O. Persico
Thread Previous
|
Thread Next