Prev: cannot freeze my gems
Next: LOGIN INTO YAHOO
From: hemant on 29 Apr 2010 14:25 On Thu, Apr 29, 2010 at 10:56 PM, Robert Dober <robert.dober(a)gmail.com> wrote: > On Thu, Apr 29, 2010 at 2:31 PM, hemant <gethemant(a)gmail.com> wrote: > Hmm, can you? I am not that sure, here is the behavior I was thinking about: > > def with_stdout stdout, &blk > original_stdout = $stdout > $stdout = stdout > blk[] > ensure > $stdout = original_stdout > end > Fair enough, may be in that pattern. But for general usage, #reopen suffices. But in any case, it may be bikeshedding to further press the point. :D -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
From: Robert Dober on 29 Apr 2010 15:06 On Thu, Apr 29, 2010 at 8:25 PM, hemant <gethemant(a)gmail.com> wrote: > Fair enough, may be in that pattern. But for general usage, #reopen > suffices. But in any case, it may be bikeshedding to further press the > point. :D No I do not think so, by using $stdout you are just conceding to the fact that it is not a constant. STDOUT is somehow a misconception. R. -- The best way to predict the future is to invent it. -- Alan Kay
From: Benoit Daloze on 29 Apr 2010 15:54 [Note: parts of this message were removed to make it a legal post.] On 29 April 2010 21:06, Robert Dober <robert.dober(a)gmail.com> wrote: > On Thu, Apr 29, 2010 at 8:25 PM, hemant <gethemant(a)gmail.com> wrote: > > Fair enough, may be in that pattern. But for general usage, #reopen > > suffices. But in any case, it may be bikeshedding to further press the > > point. :D > No I do not think so, by using $stdout you are just conceding to the > fact that it is not a constant. > STDOUT is somehow a misconception. > R. > -- > The best way to predict the future is to invent it. > -- Alan Kay > > Hi, If I can add my thoughts: STDIN, STDOUT, STDERR are constants which represent default values for $stdin, $stdout, $stderr. Programming Ruby 1.9 say: "$stdout IO The current standard output. Assignment to $stdout is not permitted: use $stdout. reopen instead." (in 1.9.2 I don't have any problem on doing "$stdout =", while I usually use $> instead) ("$> IO The destination of output for Kernel#print and Kernel#printf. The default value is $stdout.") "STDOUT IO The actual standard output stream for the program. The initial value of $stdout." In fact, the only clean way to keep the standards in/out/err is to keep unmodified these constants (which is normal: they are constants). (By clean I mean not making others constants/global variables) IO#reopen is kind of a trick that shouldn't be allowed on constants(or frozen vars), it's like a #replace. (even worse, it can actually change the class) To the main thread: Clearly, $std{out,in,err}.sync is the best way to go if you want to flush everything. :) Regards, B.D.
From: hemant on 29 Apr 2010 16:28 Hi On Fri, Apr 30, 2010 at 1:24 AM, Benoit Daloze <eregontp(a)gmail.com> wrote: > > If I can add my thoughts: > > STDIN, STDOUT, STDERR are constants which represent default values for > $stdin, $stdout, $stderr. > > Programming Ruby 1.9 say: > > "$stdout IO The current standard output. Assignment to $stdout is not > permitted: use $stdout. > reopen instead." Perhaps "not permitted" is too strong a word. Not advisable is better. > (in 1.9.2 I don't have any problem on doing "$stdout =", while I usually use > $> instead) > ("$> IO The destination of output for Kernel#print and Kernel#printf. The > default value is > $stdout.") > > "STDOUT IO The actual standard output stream for the program. The initial > value of > $stdout." > > In fact, the only clean way to keep the standards in/out/err is > to keep unmodified these constants (which is normal: they are constants). > (By clean I mean not making others constants/global variables) > > IO#reopen is kind of a trick that shouldn't be allowed on constants(or > frozen vars), it's like a #replace. > (even worse, it can actually change the class) Ruby standard library uses IO#reopen many places on STDOUT. I am not saying since Ruby standard library does that, it has to be best practice, but in above context it really depends on implementation. For example, in many languages you can have a constant variable and while you can't assign anything else to variable you can add/remove stuff to object to which the variable points. How is reopen different that that? How can reopen change the class btw? Ruby is not a class oriented language btw. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
From: Robert Dober on 29 Apr 2010 16:34
On Thu, Apr 29, 2010 at 9:54 PM, Benoit Daloze <eregontp(a)gmail.com> wrote: > On 29 April 2010 21:06, Robert Dober <robert.dober(a)gmail.com> wrote: <snip> > "$stdout IO The current standard output. Assignment to $stdout is not > permitted: use $stdout. > reopen instead." > (in 1.9.2 I don't have any problem on doing "$stdout =", while I usually use > $> instead) so this is obviously false and reopen will not do the trick if I want to intercept messages passed to $stdout. > ("$> IO The destination of output for Kernel#print and Kernel#printf. The > default value is > $stdout.") Hmm redfining $> instead of $stdout might indeed be a better idea for capture of "standard" output. <snip> agree with everything else. R. -- The best way to predict the future is to invent it. -- Alan Kay |