Would it negatively impact performance to do a type check? If the input is
a MapEntry, use the current key/val, and then use nth for other cases.
On Wednesday, 4 May 2016 10:52:35 UTC-7, Alex Miller wrote:
>
> Yes, there were some changes relating to tuples in the 1.8 alphas that
> made
Yes, there were some changes relating to tuples in the 1.8 alphas that made
2-element vectors valid map entries. However, this was done by having
IPersistentVector extend IMapEntry which meant that (from a type
perspective) all vectors were valid map entries. In practice, this led to
some
I'm also wondering if there is any advantage at all to using key/val over
first/second. The only downside I can see is that the code won't be clear.
On Wednesday, 4 May 2016 09:52:40 UTC-7, adrian...@mail.yu.edu wrote:
>
> I may be misremembering here, but I think this was briefly implemented
I may be misremembering here, but I think this was briefly implemented for
an alpha release of 1.8.0. I think the entire feature in question is being
reworked for the future, but I'm uncertain of the details. Perhaps others
can chime in with the background motivating those changes and
I've noticed that, in Clojure, there is a MapEntry type that supports the
operations "key" and "val", but in Clojurescript, MapEntry is replaced by
simple 2-element vectors.
Furthermore, 2-element vectors can be used in almost all other cases where
a MapEntry is expected, and MapEntries
