Perry, 1. Thanks for the tip on using type hints! I just added them to my code and pushed it to github
2. If you take a close look at my re- * methods, I actually tried to enforce an arity of 2 on as many methods as I could. This way the methods would read like so (re-split input-sting work-instructions) (re-partition input-sting work-instructions) (re-gsub input-sting work-instructions) (re-sub input-sting work-instructions) However, this didn't quite work with the lowest levels of re-gsub and re-sub, and forcing a map at the lowest level didn't feel right. 3. Library location is a slight issue. I agree these methods are in a completely different category than downcase, upcase, etc. The current str-utils.clj file has these methods in it. That is why they started there. There may be a case for creating a separate regex- utils library, and I know I have a few more parsing methods I'd like to propose in the near future. At the current moment, I personally prefer to have everything in one file. We'll see how big things get, though. To Everyone, I'd like to add Perry's type-hinting argument to the list of reasons these changes should be in contrib. Pooling our efforts to create a high performance version of the code does add value beyond a simple wrapper. A *fast*, tested and slick string library is even better than a tested and slick string library. Sean On Mar 25, 3:08 pm, Perry Trolard <trol...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
