From: ES <ruby-ml@...>
Date: 2005-06-06T00:30:00+09:00
Subject: Re: unbinding a Proc?


Le 5/6/2005, "Yukihiro Matsumoto" <matz@ruby-lang.org> a �crit:
>Hi,
>
>In message "Re: unbinding a Proc?"
>    on Sun, 5 Jun 2005 23:14:58 +0900, ES <ruby-ml@magical-cat.org> writes:
>
>|Proc#rebind would be very useful but I am still waiting for
>|a full-blown first-order method conversion, too.
>
>Can you explain what you want?  I am not sure how Proc#rebind would
>work, nor "a full-blown first-order method conversion".

Rebinding: normal binding works this way (as you probably know:):

class A
 attr_accessor :a
 def foo b
  @a = 'in A'
  b.bar {puts self.a}
 end
end

class B
 attr_accessor :a
 def bar(&p)
  @a = 'in B'
  p.call
 end
end

a = A.new
b = B.new
a.foo b    # => 'in A'

Same applies for all other circumstances, as well, the block is
bound at the time of its creation. While this is typically quite
satisfactory, on occasion it would be useful to rebind the block
at another location -essentially, it would be the same as (from
our example) eval()ing the {puts self.a} again wherever the #rebind
is called.

"Full-blown first-order method conversion": conversion referring
to change from the current way of working methods.. this idea is
perhaps best described by a hypothetical syntactic sugarization:
currently, def methodname is a primitive (not a method call itself),
but it could actually be a method that takes a block (the method
body) and binds it at the call location (i.e. to the class it is
defined in).

At the basic level, everything would be based on blocks, methods
just being a specific use case (probably with some convenience
added). A method dictionary might be a good way to think about
it for methods.

I have dabbled in trying to implement this (and it should not be
too hard for more experienced developers, although it would be
a shift in paradigm); the main problem I have run to is to figure
out what, instead of 'def', would be the primitive operation. That
and lacking skill :)

The disadvantage I see in this type of method handling is that
it may interfere with the conceptual model if you consider that
methods (or 'behaviours') should be intrinsic and inseparable to
and from objects.

>							matz.

E

--
template<typename duck>
void quack(duck& d) { d.quack(); }