From: Trans <transfire@...>
Date: 2005-08-08T08:31:22+09:00
Subject: Re: new block notation (was: Re: ruby-dev summary 26468-26661)

Okay, one last post and then I'll shut-up about it. I thought of a way
that it might clarify how there's another quite valid way to look
at/approach these differences between Method, Lambda, Block and Proc.

Start with my hypothetical supreme unified anonymous function object,
the MethodLambdaBlockProc.

  f = MethodLambdaBlockProc.new { |x| x % 2 == 0 }

Now instead of the typical need for Proc.new, lambda { }, &lambda, and
all that cleverness, we simply tell the MethodLambdaBla...er...f, how
to _behave_.

  [1,2,3].each f.as_block
  f.as_lambda.call(2)
  f.as_proc.call(2)
  f.as_unboundmethod(:ameth)
  f.as_method(:ameth, obj)

You might think that this is like using #to_xxx and you'd be right
except in this case its not a differnent class of object being
returned, just the same object in a different mode. This is possible
because the remaining data structure of all of them is essentially the
same (only the binding, bound vs. unbound, is substantially different).
So,

f.as_lambda
=> #<MethodLambdaBlockProc:0xb7d02db0 @mode=:lambda>

Now just as to_xxx in certain contexts is used to coerce an object into
another type, so too could a MethodLambdaBlockProc be coerced into
another mode depending on how its being used. Of course there still can
be "short-cuts" for giving direct indication of the mode such as the
operator &.

I hope the above has clarified this alternate perspective and its
potential for conceptually simplifying the whole
method/lambda/block/proc zoo. I'm not sure anyone really understood
what I was trying to say before.

T.