| Type | Wish | Status | submitted | Date | 21-Nov-2010 23:18 |
|---|---|---|---|---|---|
| Version | alpha 110 | Category | Datatype | Submitted by | BrianH |
| Platform | All | Severity | major | Priority | normal |
| Summary | STRICT-MAP! datatype |
|---|---|
| Description |
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. |
| Example code |
; Desired behavior
>> make strict-map! ["a" 1 "A" 2]
== make strict-map! [
"a" 1
"A" 2
]
>> select make strict-map! ["a" 1 "A" 2] "a"
== 1
>> select make strict-map! ["a" 1 "A" 2] "A"
== 2
|
| Assigned to | n/a | Fixed in | - | Last Update | 21-Feb-2014 01:52 |
|---|
| Comments | |
|---|---|
|
(0002915)
BrianH 21-Nov-2010 23:21 |
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). |
|
(0002974)
maxim 13-Dec-2010 05:58 |
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.
|
|
(0003216)
Ladislav 26-Oct-2011 20:51 |
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. |
|
(0004259)
BrianH 21-Feb-2014 01:52 |
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. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 21-Feb-2014 01:59 | BrianH | Comment : 0004259 | Modified | - |
| 21-Feb-2014 01:58 | BrianH | Comment : 0004259 | Modified | - |
| 21-Feb-2014 01:52 | BrianH | Comment : 0004259 | Added | - |
| 26-Oct-2011 20:51 | Ladislav | Comment : 0003216 | Added | - |
| 13-Dec-2010 05:58 | maxim | Comment : 0002974 | Added | - |
| 21-Nov-2010 23:21 | BrianH | Comment : 0002915 | Added | - |
| 21-Nov-2010 23:18 | BrianH | Ticket | Added | - |