Dave Burt wrote:
> * Rename Rio#copy to Rio#copy_to

> * Add aliases:
>   * append_to >>
>   * copy_from <
>   * append_from <<

This change has been checked into CVS, and will be in the next release.

> * Change + and =~ to use to_str instead of to_s.

This change has been checked into CVS, and will be in the next release.


> * Add the following Pathname functionality:
>   * mountpoint?
>   * root?
>   * realpath
>   * cleanpath

These will be included, but I have not finished evalutating their
integration into Rio.

> * Instead of the no* methods, you could add a wrapper ("except" or "skip"...
> or both) which could be passed into methods like so:
> io(foo).recurse(except(".svn")) {||...}.

When I was pondering a scheme for selection and rejection of files,
lines, etc.  I decided from the start, that one thing I would
absolutely avoid is the introduction of a sub-language. I have seen
too many libraries do this only to become unusable to the casual
user. Rio's grande selection methods accept a Proc to deal with the
most general case and they accept every possible parameter type I
could dream up to handle most common cases. In my opinion, as readable
as 'except' is, it falls into the category of a sub-language.

> Also, I there is a bug in io1.rel(io2) when io1 is absolute and io2 is
> relative.
I will look into this. Thanks. A specific example would be helpful.

>
> >>   * each_filename (iterates over path components: "a/b/c" -> "a", "b",
> >> "c")
> > rio('a/b/c').filenames.each ?
>
> That seems to fit the Rio way of doing things better. I assume that would
> imply you can give a block straight to #filenames and it will pass it to
> #each.
>

Rio#split returns an array of filenames, as described. This is not the
same as what you propose. Were #filenames a Rio configuration method,
it would take a block directly. This seems like a solid proposal. I
need to give this a little more thought, but at this point I am
inclined to dump #split in favor of #filenames.

> >> * If Rio provided a superset of IO's functionality, you could use Rio
> >> objects in place of IO objects, duck-type style. Same with File, Dir and
> >> Pathname.
> > The section "Using A Rio as an IO (or File or Dir)" in Rio::Doc::INTRO
> > discusses this, with an illustration using a Rio with yaml.
>
> I still think it would be fairly easy to have Rio able to replace IO, Dir,
> File, Pathname in _all_ situations. Maybe this extra clutter would be best
> placed in a mixin.
>

Ignoring the *big* problem with #<<, as described in RIO::Doc::INTRO,
Rio is close enough that it would be a shame not to allow a Rio to be
used anywhere an IO is. You have won me over on this one. Ditto File
and Dir

Off the top of my head, what would you think of an emulation mode
 rio(...).likeio
or somesuch?
Describe how you see a mixin working.

Pathname is another matter. IO, File and Dir are integral parts of
Ruby.  Pathname is not. I am not convinced that providing emulation
of legacy libraries such as Pathname should be a priority.

> * Add pipes. The following should be possible:
> io(foo) | io(bar) | io(baz)

I still love this idea. After revisiting it, I remembered why I had
put it aside before. Its behaviour is obvious in some cases ie. where
'foo' is a file, and 'bar' is a cmdio and 'baz' is a file, or if they
are all cmdios. It becomes murky to me what the behaviour should be
if, for instance, they are all files.

To generalize, for duplex streams, piping is clear, but for non-duplex
streams, what exactly does piping mean?

One possibility that comes to mind is making it simply a copy-to in
those cases. That would make possible the following:

 # tee the output of 'acmd' to a file and to stdout.
 rio(?-,'acmd') | rio('output_file') | rio(?-)

Another possibility, is to simply raise an error unless one of the
participants is a duplex-stream.

Another possibility, is that I don't understand what you are proposing.

This is too elegant to not be included in Rio. I need help defining
what its behaviour should be.

Cheers,
-Christopher