Whatever it's worth as a datum, my experience is that I usually find myself writing upcase, downcase, titlecase functions in most applications, because
(1) they're prettier & more succinct when passed as first-class (downcase vs. #(.toLowerCase %)) (2) I can add type hints once, in the downcase, upcase, etc. functions, instead of doing so at each invocation (#(.toLowerCase #^String %)) I think (2)'s the most compelling reason. The type-hinting situation in Clojure is currently pretty impressive, I've found; a relatively small number of hints strategically placed usually eliminate most or all of the reflection that occurs in my first draft of functions. But many string-processing operations -- for whatever reason -- usually need a manual hint. I agree that it's not desirable to balloon the Clojure API with thin wrappers on the Java APIs, but, like pc, think this might be an exception. I'm less sure about the other proposed changes to str-utils -- the variable-arity versions of re-split, -partition, -sub, -gsub. Maybe a regex-parse lib in contrib would be a better place? Perry --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
