Oldes
commented
3 years ago I already added map! compatible with Red and one can use select/case:
>> m: #("a" 1 "A" 2)
== #(
"a" 1
"A" 2
)
>> select m "A"
== 1
>> select/case m "A"
== 2Closed Siskin-Bot closed 3 years ago
Oldes
commented
3 years ago I already added map! compatible with Red and one can use select/case:
>> m: #("a" 1 "A" 2)
== #(
"a" 1
"A" 2
)
>> select m "A"
== 1
>> select/case m "A"
== 2
Submitted by: BrianH
This would be like the map! type, but case-sensitive. Word binding would not be considered, only case, so it wouldn't be fully STRICT-EQUAL? compatible, but it would be close enough for the name to make sense. In all other ways it would behave like map!, and the two could likely share a lot of code.
This is a way to make a case-sensitive version of the map! type without needing to specify an option, which the syntax of the map! spec makes impossible (#1437), and it won't break normal usage of the map! type (#1315). If this is accepted, a hash! type (#1494) will likely be unnecessary.
Originally suggested by Andreas in a #1494 comment, or maybe by me in AltME, I don't remember which.
Imported from: CureCode [ Version: alpha 110 Type: Wish Platform: All Category: Datatype Reproduce: Always Fixed-in:none ] Imported from: https://github.com/rebol/rebol-issues/issues/1774
Comments:
Submitted by: BrianH
The severity is high because adding a new datatype is a big deal, not because of any opinion of the priority of the request (that is for someone else to decide).
Submitted by: maxim
I'll (try ;) to add weight to this ticket by saying that I find it very important to be able to have case sensitive maps. A lot of the real world data IS case sensitive, and can't be precisely indexed with map! right now.
Submitted by: Ladislav
Just to not forget, I am adding the circumvention: strings can be converted to binary, in which case the comparison becomes case sensitive, in fact.
Submitted by: BrianH
A proposal for a tweak to this suggested in SO chat:
We could make this even more strict by having the value that indicates that a key should be removed from the map be #[unset!] instead of #[none]. The advantages of this include being able to remove keys (like in maps), but still being able to treat the absence of a key as an error (like unset words in objects). Using SELECT on a strict-map! for a missing key would still return #[none], as it does with objects. This would also make the semantics of strict-map! a strict superset of the really common JSON object semantics (also shared by YAML and many other data formats), allowing easy processing of that kind of data.
The downside is that you would have to use POKE or APPEND to unset a key - set-path expressions wouldn't work. This restriction might be a good thing though, to cut down on potential bugs.
The equivalent workaround to make map! usable for this requires not only converting to binary keys, as Ladislav mentioned above, but also converting the null values to #[unset!] and making all map-handling code unset-tolerant. That code pattern can be pretty awkward and have a lot of overhead, so maybe between the two differences this might justify having a new type.