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, but they are not mandatory, so there will still be situations in which an unexpected (and difficult to understand) value would be passed around for a while. Since it's fairly easy to change and may save people a lot of debugging time, perhaps the change should be considered.
The behavior of blank? is less likely to cause problems in practice and perhaps a bit harder to fix, so it's less of an issue, I suppose, but it's just unexpected (especially to those coming from statically typed languages) that it works on false and not on true. Elena On Tuesday, June 21, 2016 at 4:42:08 PM UTC-5, Sean Corfield wrote: > > On 6/21/16, 1:28 PM, "Alex Miller" <clo...@googlegroups.com <javascript:> > on behalf of al...@puredanger.com <javascript:>> 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 you get well-defined > behavior but the language does not specify what particular well-defined > behavior you get (and the implementation is not required to document it). > Undefined behavior is where you may get _any_ behavior (and, again, the > implementation is not required to document it). There is also > implementation-defined behavior where the language does not specify the > behavior but the implementation _is_ required to document it (and it > represents correct code). > > This is undefined behavior. > > (Sorry, that’s what nearly a decade of ANSI Standards Committee work does > to someone!) > > > A nil is not a string and should be distinguishable from an empty string > in many cases. > > We disagree on the degree of punning here ☺ I’m not asking for the change. > I understand why it is the way it is (I just don’t like it ☺). > > > blank? follows the rules of clojure.string you stated above (other than > it's stated extension to also cover nil). > > Good point. Yes, I’m persuaded. > > 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.
