From: ntalbott@...
Date: 2002-01-30T03:57:29+09:00
Subject: RE: Proc hash bug?

Yukihiro Matsumoto [mailto:matz@ruby-lang.org] wrote:

> <ntalbott@rolemodelsoft.com> writes:
> 
> |I would have expected the proc to still have the same hash as itself!

> |This behavior also occurs for me on 1.6.4. Is this a bug? If not, 
> |what's the feature?
> 
> Current implementation converts Proc <-> Block for each time, 
> so that &var Proc is generated each time.  This might change 
> in the future, but I cannot ensure the hash (or identity) equality.

This breaks POLS for me in a big way (but maybe not for you). I expect
the block to remain the same whether I pass it in through the arguments
as an object, or whether I use & to associate it directly with the
method call. I can see why, implementation-wise, it might be easier to
make them different, but I can't see from a user's perspective how the
behavior makes sense.

Let me try to explain what I'm doing, and then you can tell me if my
surprise is misplaced or unnecessary. Basically I'm working on an
interface to store a bunch of procs in an object and manipulate them
after I store them, something like this:

	my_proc = proc_store.add_proc { ... }
	thing.remove_proc(my_proc)

There's more to it than that, but you get the idea. The obvious way to
do this is to store the procs in a hash that is an instance variable of
the proc_store, but if I do that, the above won't work, since passing
procs through the & mechanism munges them. Instead I have to do this:

	my_proc = proc { ... }  # this is necessary so I can remove the
proc later
	proc_store.add_proc(my_proc)
	proc_store.remove_proc(my_proc)

This adds an extra step and violates my POLS for the interface I'm
working on. If there's a good reason for munging the procs, I'm willing
to go with a less attractive alternative, but I guess I'm looking either
for more of an explanation or a fix. I'd submit an RCR for it if you
think it's worthwhile.


Nathaniel

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI