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.

Reply via email to