It doesn't necessarily follow that something that works with
clojure.core/get needs to work with clojure.core/assoc. You can have an
object that implements ILookup but not Associative, for instance.
The problem with using assoc with native JVM data structures like strings
and arrays is that there isn't an efficient way of implementing assoc for
those structures. You have to copy the entire structure, no matter how
large it might be. Clojure seems to avoid having functions that have
variable performance depending on the data structure they're applied to.
For example, trying to "get" on a seq also fails, presumably because seqs
have no efficient way of looking up a value by index. Instead we have
clojure.core/nth, which has predictable O(n) performance.
- James
On 21 April 2016 at 16:48, Mars0i <marsh...@logical.net> wrote:
> The docstring for 'get' says nothing explicit about vectors ("Returns the
> value mapped to key, not-found or nil if key not present.") but most of us
> know that vectors can be viewed as associative data structures where
> indexes are like keys:
>
> (get [\a \b \c] 1)
> \b
>
> 'get' also works on strings:
>
> (get "abc" 1)
> \b
>
> However, strings are not treated as vectors or maps in other contexts:
>
> (assoc "abc" 1 \Z)
> ClassCastException java.lang.String cannot be cast to
> clojure.lang.Associative
>
> This combination of behaviors is confusing. If strings are vectors, then
> 'assoc' and other similar functions should work with them, and maybe I
> should be able to do this to index into a string:
>
> ("abc" 1)
> ClassCastException java.lang.String cannot be cast to clojure.lang.IFn
>
> If strings are not vectors, then they seem to be a special case for
> 'get'. One might argue that the very terse docstring for 'get' should note
> its use with vectors, but once you understand the sense in which vectors
> are like maps, the of 'get' use with vectors is implicitly covered by what
> the docstring says. However, the use of 'get' with strings is not
> implicitly covered by what the docstring says. If it was, then the last
> two examples I gave should work.
>
> (I'd be willing to file a ticket on this, but the puzzling behavior is not
> new, and I suspect that there's something I'm not understanding.)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
