------art_227070_30361958.1169569444998
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/23/07, ara.t.howard / noaa.gov <ara.t.howard / noaa.gov> wrote:
>
> 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.


I completely agree, but I feel that the argument teaches me a lot.

>
> > But is it really true, that after
> >
> >  m  .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  .new
> >  m  .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.


That is very interesting but funnily enough IMHO it makes it even more
counter-intuitive to call a m's receiver.
As a matter of fact I know that I cannot go into the depth of the
implementation that is why I have asked the question:
"Do we agree  that the only thing having a receiver is a message"
Obviously we do not.
But in that case, what can have a receiver? A method? A method-call? A
method object?

OMG we might end up in an endless loop.


>
> > 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  .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.


... by fixing the code, yep that is an excellent argument, but it is not
true in all cases

m .method(:x)
m.unbind
m.bind(a.class.new)

so at least the decision you were talking about was not final, the code
stays the same but the receiver changes.
I try hard to figure if one can argument as such in your setup, canyou? or
are we still miles apart?

In step 2), the
> > object's role is to execute a given piece of code in its context.


or the methods role to execute a given piece of code in a context in which
the object it is bound to becomes the receiver.

>
> > So, I would say that after
> >
> >  m  .method(:x)
> >
> > the object a has at least partly acted as a receiver.
> >
> > David, could you live with that? :-)
> >
> > Regards,
> > Pit
> >


Honestly Ara  I am disappointed by the tone of your post, I do not recognize
you, this is very  subtle a discussion and the s***y word has just no place
in it.
I would frankly ignore it by people I know less but....
Now  if I  overreact I apologize, I am not a native speaker.

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.


That is completely OT we were talking about Runtime "self" is perfectly
defined at execution of the method, while at point (x) receiver is not - but
is in your setup I start to guess that now.
m  .method(:x)
------(x)--------
a.call

you can put any code between the two lines as I have mentioned above.

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.


But given a server S and a client C, it would be incorrect to name S C's
server before C has sent a packet to S. We are clearly talking runtime and
not time of conception.

We are not saying that receiver is bad a name for an object. We think it is
bad a name for a relationship between Method and the object it is bound to
at a given state during runtime.
When the method is called the relationship between its bound object and
itself can be described as receiver before it is misleading.

'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
>
>
Robert

-- 
"The best way to predict the future is to invent it."
- Alan Kay

------art_227070_30361958.1169569444998--