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 clojure.set functions > producing “garbage” output if you give them “garbage” input (not sets). > This is the classic computer science “undefined” behavior that we see in > many other languages, where the behavior is only defined for the specific > types of inputs. >
I'm not a fan of the word "garbage" in this case or "garbage in / garbage out". I think that implies a value judgement about both input and output that is incorrect here. "specified"/"unspecified" is much better. The clojure.string functions specify the behavior for a class of inputs and leave other cases unspecified. Things that are unspecified may still be useful (but you should not rely on that behavior as it is not specified) and things that are unspecified now may become specified in the future. > I would _love_ all the clojure.string functions to be defined for nil as > an input – since we have (str nil) => “” – but adding that nil check, or > even calling str directly in clojure.string functions, adds quite an > overhead for all uses (so that proposal would never be accepted). > > Looking at the clojure.string namespace docstring, it is explicit about > nil arguments: > > “passing nil will result in a NullPointerException unless documented > otherwise.” > > This makes me sad ☺ It’s almost my only source of NPEs in my Clojure code > and I pretty much always want the empty string behavior in case of nil. Oh > well. > > The docstring also has this to say about argument types: > > “When a function is documented to accept a string argument, it will take > any implementation of the correct *interface* on the host platform. In > Java, this is CharSequence, which is more general than String. In ordinary > usage you will almost always pass concrete strings.” > > That explains why it calls toString() – to convert CharSequence (or any of > its implementations) to String. Unfortunately, much as with clojure.set > functions, if you pass any argument that is not an implementation of > CharSequence but happens to support toString() – which is nearly anything – > then you get “garbage” out because you passed “garbage” in. > > I think everyone passes a non-string value to a clojure.string function at > least once and then scratches their head at the bizarre result (which often > pops up a long way down the chain of string manipulation and therefore some > distance from the bug). > > It’s the price we pay for improved performance in the “correct” use cases > ☹ > Performance is not the only consideration here (or maybe even the prime one). A nil is not a string and should be distinguishable from an empty string in many cases. > As for blank? Yes, that seems like the docstring needs correcting since it > returns “True if s is falsey (nil or false), empty, or contains only > whitespace.” > I do not think this needs updating. blank? follows the rules of clojure.string you stated above (other than it's stated extension to also cover nil). In other words: (blank? false) is unspecified because you have passed a boolean, not a CharSequence. I would spec this as something like (s/fdef clojure.string/blank? :args (s/cat :s (s/nilable #(instance? CharSequence %))) :ret boolean?) > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > -- 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.
