From: Dave Burt <dave@...>
Date: 2005-08-29T17:41:23+09:00
Subject: Re: Rio 0.3.3

Christopher wrote:
> 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.

irb(main):002:0> rio('/usr/bin/ruby').rel('foo/bar')
=> #<Rio:0x1620220:"path:../../usr/bin/ruby" (Path::Reset)>

I'm not sure what the correct answer is; probably an exception would be 
appropriate. Otherwise, if the parameter is relative, you might want to 
evaluate it as an absolute path from the working directory.

> 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.

I was thinking of a mixin that mainly adds aliases and wrappers to 
functionality that's already in Rio. It might override #<< to be 
IO-compatible (probably retaining the Rio semantics for rio << rio). You 
could mix it in like this:
r = rio(foo)
r.extend(Rio::IO)
some_method_which_wants_an_io(r)

You could add a #to_io method:
class Rio  # I'm not sure if this is the right class to put it in - what is 
Base?
  def to_io
    clone.extend(Rio::IO)
  end
end

I'm not sure what the ethics of having a to_x method that only returns a 
duck-X, but if it does fully quack right, I don't mind.

> 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.

Fair enough. I don't get Pathname 100%, either (in particular, why is 
Pathname#chdir deprecated?)

>> * 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.

Initially I preferred the error, but the tee makes sense, even if it's a 
little less than obvious. An input-only stream is still going to produce an 
error, isn't it?

> 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.

If you like it, and you understand *nix shell process-chaining pipes, then 
you understand.

Cheers,
Dave