[#6660] Ruby on Neko ? — Nicolas Cannasse <ncannasse@...>

Hi folks,

14 messages 2005/11/19

[#6672] testing for hardlink with "test(?-, ...)" flawed on Windows — noreply@...

Bugs item #2858, was opened at 2005-11-20 16:35

13 messages 2005/11/20

[#6684] semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...>

Hi all,

81 messages 2005/11/21
[#6685] Re: semenatics of if/unless/while statement modifiers — Mauricio Fern疣dez <mfp@...> 2005/11/22

On Tue, Nov 22, 2005 at 08:22:59AM +0900, Stefan Kaes wrote:

[#6686] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Mauricio Fern疣dez wrote:

[#6687] Re: semenatics of if/unless/while statement modifiers — Eric Hodel <drbrain@...7.net> 2005/11/22

On Nov 21, 2005, at 4:37 PM, Stefan Kaes wrote:

[#6689] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Eric Hodel wrote:

[#6693] Re: semenatics of if/unless/while statement modifiers — Yukihiro Matsumoto <matz@...> 2005/11/22

Hi,

[#6695] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Yukihiro Matsumoto wrote:

[#6718] Re: semenatics of if/unless/while statement modifiers — mathew <meta@...> 2005/11/22

[#6722] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

mathew wrote:

[#6707] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6708] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6714] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6717] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6798] ruby 1.8.4 preview2 — Yukihiro Matsumoto <matz@...>

Hi,

37 messages 2005/11/30

Ruby pipes

From: "Sean E. Russell" <ser@...>
Date: 2005-11-25 15:19:29 UTC
List: ruby-core #6781
Hi,

I'm having a bit of a trouble with Ruby pipes and am looking for an efficient 
solution to the problem.

Consider:

	a,b = IO.pipe

Both a and b are IO objects, and there is nothing (that I can tell) to 
differentiate them from any other sort of IO object.  That is, there is no 
way to tell that they are pipes.  This is a failure in the typing system.

Unfortunately, not all functions on IO objects are valid for all IO objects.  
For instance:

	a.tell

which should return the current position in the stream, instead throws an 
exception for pipes.  This is behavior that Ruby inherits from C's stdio, but 
it is also a failure of the duck typing system: there exist methods that are 
defined as failing for objects of a given type, yet those methods exist for 
those objects.

So, if I have a method that accepts an IO object, it is insufficient to test 
that the object is an IO instance to ensure that the methods are valid.  The 
only way to ensure that the code works is to rescue potential errors:

	def foo( ob )
		begin
			ob.tell
		rescue Errno::ESPIPE
		end
	end

However, this is an order of magnitude slower, whether the method succeeds or 
fails.  This is unacceptable, especially because we *know* which functions 
will fail for which objects, and a kind_of? test is much, much faster.

In my current project, I *could* do the following, because of how I'm using 
the mystery object:

	class Foo
		def initialize( ob )
			@ob = ob
			begin
				ob.tell
				@pipe = false
			rescue Errno::ESPIPE
				@pipe = true
			end
		end
		def foo
			@pipe ? 0 : @ob.tell
		end
	end

I don't know about the rest of you, but this is hackery to the extreme.  I get 
a creepy, slimy feeling just looking at it.  And this only works because of 
how I'm using the code; if I'm providing a function where the object is being 
passed in every time, I can't use this trick.

As I said before, Ruby inherits this problem from C, so it isn't something 
that could be easily fixed in Ruby (I think).  Two ideal solutions would be:

	1) Pipes are a subclass of IO, and can be tested as such
	2) Pipes don't expose IO methods that are known to fail,
	    so respond_to? could be used to duck-type them.

(2) would break all sorts of class inheritance rules, and this situation is a 
good example of a fundamental flaw in mixing duck typing and OO -- but that's 
a different thread.  In any case, neither solution is likely to happen, so my 
question boils down to:

Is there no other way to solve this without either (a) incurring the huge 
performance hit of relying on exception handling for branching, or (b) 
resorting to an ugly hack?

-- 
--- SER

"As democracy is perfected, the office of president represents, 
more and more closely, the inner soul of the people.  On some 
great and glorious day the plain folks of the land will reach 
their heart's desire at last and the White House will be adorned 
by a downright moron."        -  H.L. Mencken (1880 - 1956)

In This Thread

Prev Next