Okay, I've made some changes to my proposed str-utils. I've also got a few answers to some of the issues Stuart raised.
New Changes 1. re-strip is now lazy I re-wrote this method to used the re-partition method in str-utils. This enables the laziness, and helped be consolidate my Java interactions into fewer functions. 2. re-strip options changed I removed the ability to pass a :limit option. I replaced it with :offset and :length options. Seemed to make the function more flexible :) 3. created nearby function The nearby function returns a lazy sequence of strings "nearby" the input string. It's inspired by the Norvig spellchecker example. I'd like to propose adding this method to the library, because I'm interested in what uses creative people will have for it. 4. Added README.html This file contains usage on every method in my proposed str-utils Response to Stuart's Issues You've raised some good points with my proposal. However, I think there is some hidden value in including the functions in the library. 1. Repeated The main reason I have for including the repeated methods (trim,strip,downcase,upcase) in the str-utils library is program flow. Take the following two examples (map downcase a-list) (map #(. % toLowerCase) a-list) It's my purely subjective opinion that the first method reads much nicer. I'm also a web developer, so I do a lot of string processing. I have a subjective preference for functions that make code more concise, and my code will read a little shorter with the downcase function in it. I guess my main argument is that a more concise way of stating the same thing does add value. For example, the jQuery selector can be called using the function jQuery(). However, it is always written $() to save time. In my view, the $() shortcut does add value. This is why I think you should consider adding my repeated methods to str- utils. 2. Methods in Apache Commons The second issue you raise is with methods like capitalize, that are available in Apache Commons. First of all, the exact reasoning I went through above could easily be applied to the following s-exp (map capitalize a-list) However, I believe there is an additional reason for including these methods in the library. By requiring Apache Commons, you've increased the number of jars I need to maintain. Granted, a lot of people are used to using the commons. It is still one more thing that requires maintenance, though. By making capitalize (and others) part of contrib, it reduces the amount of work I have to do to get this functionality. In conclusion, I'd recommend making the str-utils one of the slickest libraries in Clojure. As developers, we know how strong string manipulation makes writing code easier. If Clojure has incredible string support, developers will be more impressed. Let's go out of our way to make string manipulation in Clojure easier than in any other language. Besides, once we get a kick-ass string library working, we can then abstract the routines to work on any pattern of symbols, and give our macro writers a boost. Sean On Mar 24, 2:22 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > On Mar 23, 9:46 pm, Sean <francoisdev...@gmail.com> wrote: > > >http://github.com/francoisdevlin/clojure-str-utils-proposal/tree/master > > > I'm not sure what the directory structure should be for everything > > still. Perhaps somebody can point out how it should be done. > > > I'll put the original post in the README > > > Long story short: multi-methods could be awesome > > Hi Sean, > > This is interesting. One quick comment, though: the trim, strip, > upcase, and downcase functions don't add anything to the original Java > methods. Rich and others have warned against adding wrapper functions > just to hide Java. > > Some of these functions, like capitalize, are available in Apache > Commons Lang, the "StringUtils" class. > > -Stuart Sierra --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
