From: "David A. Black" <dblack@...>
Date: 2005-08-30T08:52:52+09:00
Subject: Re: Method behaves differently when called using #send

Hi --

On Tue, 30 Aug 2005, Ara.T.Howard wrote:

> On Tue, 30 Aug 2005, David A. Black wrote:
>
>>>  dispatch(a_message, *args, &block)
>>> 
>>>  post(a_message, *args, &block)
>> 
>> My problem with this kind of name is that it isn't clear which one would
>> include private methods and which one wouldn't.  It would be arbitrary, and
>> one would just have to memorize it (and, in explaining it, would probably
>> have to account for it as being "for historical reasons" or some such).
>
> hmm.  true.  but that is true of send too - one must memorize that
> only public methods are available... and then what about protected?
> the whold thing doesn't seem that un-arbitrary.

If send is redefined to be strictly a programmatic equivalent to the
object.message syntax, then the public-only thing would fall into
place.  But then there's the need for a second name....

> why not address the whole thing using some
> sort of object orientied approach:
>
>  PublicView( obj ).send 'a_public_method'
>
>  FriendView( obj ).send 'a_protected_method'
>
>  PrivateView( obj ).send 'a_private_method'
>
> where
>
>  class PublicView < View
>    ...
>  end
>  def PublicView(*a, &b); PublicView::new(*a, &b); end
>
> etc.
>
> not seriously suggesting these names, but you get the idea: views of
> objects that handle the same 'ol methods (like 'send') in different
> ways.

I see what you mean, but I'm not sure why that would be a more OO-ish
approach, since it sort of offloads the responsibility for the
object's handling of messages to something other than the object.  I'd
like to retain something a bit lower-level, or closer to the object,
or something -- and maybe the kind of View thing you're describing
could be built on top of it.


David

-- 
David A. Black
dblack@wobblini.net