I wasn't saying that the functions implementation is incorrect (it does
follow the specification). However, I think 'capitalize' obscures the error
in the case when it would've been easy to fail early and produce meaningful
error reporting (as 'reverse' does). Adding spec conditions would help,
On 6/21/16, 1:28 PM, "Alex Miller" wrote:
> I'm not a fan of the word "garbage" in this case or "garbage in / garbage
> out".
For me there’s no judgment involved in the “GIGO” principle but fair enough.
> "specified"/"unspecified" is much better.
It’s inaccurate. Unspecified behavior is where
On Tuesday, June 21, 2016 at 2:45:45 PM UTC-5, Sean Corfield wrote:
>
> Alex gave you a correct (but fairly short) answer. I’d like to expand on
> it a bit, partly in light of a certain recent blog post, partly because of
> a personal “hot button”…
>
> This is going to be along the same lines as
Alex gave you a correct (but fairly short) answer. I’d like to expand on it a
bit, partly in light of a certain recent blog post, partly because of a
personal “hot button”…
This is going to be along the same lines as clojure.set functions producing
“garbage” output if you give them “garbage” in
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 (
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
une
