I think something more abstract would be good. A function or macro where you pass it an "IO Spec" and it takes care of all the class stuff.
(io/read [:bytes :from <SOMETHING> :as p] (do-stuff-with-a-byte p)) (io/read [:lines :from <SOMETHING> :as p] (do-stuff-with-a-string p)) (io/read [:lines :from <SOMETHING>]) ;no :as binding or body, results in a lazy-seq of lines so you can specify the IO behavior you want, and let the implementation map the spec to a class. that being said, you would still want something like duckstreams for interop, and possibly io/read and io/write would be implemented using duckstreams. So I see no harm in pulling duckstreams in. P.S. scopes are great for the lazy-seq case On Fri, Jan 1, 2010 at 1:34 PM, Phil Hagelberg <p...@hagelb.org> wrote: > Sean Devlin <francoisdev...@gmail.com> writes: > >> 1. I'd recommend adding support for general unix file utilities. >> I've written some of them myself, and you can review/borrow/steal code >> from here: >> >> http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/src/lib/sfd/file_utils.clj > > These are all one-line wrappers around Java methods. I know Rich has > stated that the Clojure philosophy is to avoid such wrappers unless they > provide significant additional value. Perhaps this will need to change > as people start to write more cross-platform code, but I don't know if > we're to that point yet. > >> 2. duck-streams works very well for text, but not binary formats. I >> know there was discussion about it here: >> >> http://groups.google.com/group/clojure/browse_thread/thread/416ca90d3ce2fa3/d64648f34e5c8668 > > I believe it's the case that reader and writer don't work for binary > formats, but copy should. Copying between two files or between a file > and a byte array should work fine unless I'm missing something. This > should be better-documented though. > >> 3. There should be a brainstorming session to see what objects reader/ >> writer will dispatch over, and the multimethods improved accordingly. >> This should probably happen anyway. > > It covers everything I can think of, but if you've got suggestions let's > hear them. > > -Phil > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
