First of all, good idea to have a dedicated string library in core. we use String manipulations often enough to make that worthwhile.
The goal should be on making operations easy and efficient. Mostly a string is just a value like 42, 1.25 or 27-MAY-2010, calling for simple "arithemetic" functions. In some cases a string can be seen as a generalised seq, but I think they are the situations where you dont want a dedicated string library. Therefore I have a little doubt with the implementation of join. It is a beautiful implementation but not really efficient. Some (nasty looking) implementation directly using a stringbuilder is more efficient. (about 2.5 times according to my measureements) On another line, I found a little bug in the version found in github - The macros make assertions using 'vector', and therefore accept bindings in list form: (assert (vector bindings)) which presumably should have been this: (assert (vector? bindings)) And good points from Stefan, below. Clarity to semantics is important, and especially for such a basic thing as a string library. More generally, i would like to see some overall design principles - does the library accept nil in place of string arguments? - some functions do / some not. When are characters acceptable in place of strings, etc No criticism, of course, I fully support the work done. > sorry, I'm a little late. However, to me it is not clear what the > trim functions shall do. If they become a replacement for chomp they > are clearly misnamed. In many applications and languages (like Excel, > several SQL variants, oh, and Java, ...) "trim" means stripping of > whitespace characters, including but not limited to \n and \r. In > contrast to that chomp stands for the removal of the system-specific > linebreak. > > Usually trim-functions accept an optional list of chars to trim. So > if a trim function would be implemented as a char-remover, defaulting > to whitespace, and chomp would then be equivalent to (trim "foo\n" "\r > \n") -- the second arg should probably something seqable -- everything > seems fine to me. > > Just my 2ct > Stefan -- 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
