On Wed, 24 Jan 2007, Pit Capitain wrote:

>
> To me, the main point of this discussion so far has been whether we should
> call an object a receiver if it only plays the *role* of a receiver but
> hasn't *acted* as a receiver yet. David et al. think this would be
> misleading, others (me included) don't think so. We could go on and on and I
> don't think we'll come to an agreement.
>
> But is it really true, that after
>
>  m = a.method(:x)
>
> the object "a" hasn't acted as a receiver yet? Look at this code:
>
>  class C
>    def x
>      "x of #{self}"
>    end
>  end
>
>  a = C.new
>  m = a.method(:x)
>
> The method C#x hasn't been executed yet. Let's do it in two ways:
>
>  puts a.x     # => x of #<C:0x2ae912c>
>  puts m.call  # => x of #<C:0x2ae912c>
>
> Now we change the implementation of the method:
>
>  class C
>    remove_method(:x)
>    def x
>      "new x of #{self.inspect}"
>    end
>  end
>
>  puts a.x     # => new x of #<C:0x2ae912c>
>  puts m.call  # => x of #<C:0x2ae912c>
>
> The BoundMethod object "m" still uses the old definition. Even after removing 
> the method...
>
>  class C
>    remove_method(:x)
>  end
>
>  puts a.x rescue puts $!  # => undefined method `x' for #<C:0x2ae912c>
>  puts m.call              # => x of #<C:0x2ae912c>
>
> ...we are still able to execute the old implementation. So, if I look at this 
> example, I don't think that
>
>  m.call
>
> is really sending a message. It just executes the implementation it has 
> remembered in the context of the original object.
>
> What happens when an object receives a message?
>
> 1) Search a method for the message in the object's classes/modules.
> 2) Execute this method in the context of the object.
>
> If the steps 1) and 2) are separated as in...
>
>  m = a.method(:x)
>  m.call
>
> ...I would even say that the receiving part has occurred in step 1), where 
> the object decides how it wants to react upon the message. In step 2), the 
> object's role is to execute a given piece of code in its context.
>
> So, I would say that after
>
>  m = a.method(:x)
>
> the object a has at least partly acted as a receiver.
>
> David, could you live with that? :-)
>
> Regards,
> Pit
>

very good points.  frankly, i find the 'potentiality' arguments silly since
they're analogous to saying the we shouldn't use 'self' here

   class C
     def m() self end
   end

since, at the time of writing the function, no 'self' yet exists.  to be
accurte we should probably use

   class C
     def m() furture_self end
   end

but, of course, we don't.

the point is that, unless code executes as you write it, we are __always__
deferring the framing context to the time of execution and chosing terms that
make sense in that potential context.  we use 'server' and 'client' even if no
packets will be sent.  'producer' and 'consumer' and meaningful event when no
events transpire.  'source' and 'sink' are perfect logical titles to relay
meaning as are 'receiver' and 'message'.  the eventuality or potentiality
have, imho, little to do with the use of these terms to define primary
relationships between objects.

regards.


-a
-- 
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama