From: Robert Dober on
On Fri, Apr 30, 2010 at 9:43 AM, Charles Oliver Nutter
<headius(a)> wrote:
> On Fri, Apr 30, 2010 at 2:09 AM, Robert Klemme
> IO.popen doesn't require IO#reopen to be available to users, so I'm
> not sure what you mean by that. It may do something similar to reopen
> under the covers, but that's an implementation detail.
Gives me the opportunity to point out that JRuby1.5 completely
supports open4 now.
That is really great!
In general I feel that abstraction is the way to go.

The best way to predict the future is to invent it.
-- Alan Kay

From: Caleb Clausen on
On 4/30/10, Robert Klemme <shortcutter(a)> wrote:
> 2010/4/30 Charles Oliver Nutter <headius(a)>:
>> On Thu, Apr 29, 2010 at 4:24 PM, Caleb Clausen <vikkous(a)> wrote:
>>> Check out this code. No other method in all of ruby has this behavior.
>>> p $stderr.class #=>IO
>>> "foo","w"
>>> $stderr.reopen(f)
>>> p $stderr.class #=>File
>> This is a really nasty feature not a lot of people know about. It's
>> not possible for us to support in JRuby because the underlying object
>> can't actually change class:
> That's true, instances which change their class - this is problematic.
>> I'm of the opinion that .reopen should be discouraged in general.
> IMHO that is a bad idea because this is the standard way how you
> redirect stderr, stdin and stdout for child processes - at least on
> POSIX systems. Any program that wants to do something similar like
> IO.popen or just wants to prevent the child's stdout to clutter its
> own output depends on the ability to do this.

I would hate to see reopen go away, but I have to agree with Charlie
that the current implementation has some pretty ugly semantics. It
seems like one ought to be able to get the same effect through
creative use of singleton classes or extend....

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: cannot freeze my gems