There are some comments at the top of clojure.string (http://clojure.github.io/clojure/#clojure.string) about expected usage. In particular, you should expect all clojure.string functions to accept CharSequence (a parent interface of String, StringBuffer, and StringBuilder and return the same (usually a concrete String). All other input types are not supported. The calls to toString() are generally a way to convert any of the CharSequence impls to a concrete String so they can be further acted upon. The results of calling any of these functions with something other than a CharSequence are unspecified.
I expect that specs on clojure.string functions will provide an additional layer of checking around this in the future. On Tuesday, June 21, 2016 at 1:45:39 PM UTC-5, Elena Machkasova wrote: > > Greetings, > > I was looking at clojure.string functions, and noticed that some have > unexpected (especially for less experienced programmers) behavior on > non-string arguments. For instance, 'capitalize' applies toString to its > argument, effectively making it possible to pass any type, but with > unexpected results. Here are some examples that may be really confusing to > novices, especially since it's not immediately obvious that the argument is > returned as a string when it's printed back: > > (str/capitalize [\a \B \c]) ; returns "[\a \b \c]" > (str/capitalize (char-array "aBc")) ; returns the address, as a string > > Interestingly, 'reverse' doesn't allow non-string arguments since it uses > a StringBuilder, and not toString, to create a string, and there are a few > other clojure.string functions that behave like 'reverse' in this regard. As > a minimum, this is inconsistent with 'capitalize'. > > As a separate issue, blank? returns 'true' when passed 'false' (since the > check is for false, not specifically for nil), but (blank? true) is a type > error. > > It is fairly easy for experienced programmers to understand what's going > on by reading the source code, but none of these behaviors are documented, > and would confuse beginners. > > Is there anything that I am overlooking in these design decisions, or > should this implementation be changed? > > Thanks! > > Elena > -- 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.