From: gwtmp01@...
Date: 2007-01-06T03:55:11+09:00
Subject: Re: Pervasive Methods [was: Little Things]


On Jan 4, 2007, at 5:34 PM, ara.t.howard@noaa.gov wrote:
> On Fri, 5 Jan 2007, Trans wrote:
>> Or maybe
>>    obj!send message
>
> that's pretty good.  i was leaning towards a module so we could  
> just try to
> write it as an extension now though...

This has been an interesting discussion but I think several related
issues have been bundled together, perhaps unnecessarily:

1) literal vs. dynamic method names

	recv.method		# method is explicitly named
	recv.send x		# method is dynamically named

2) public vs. private

	recv.private_method		# error
	recv.send :private_method	# 1.8 no error, 1.9 error
	recv.funcall :private_method	# 1.9 no error
	recv.__send! :private_method	# 1.9 no error

3) name clashes and meta programming

	recv.send	# is this Object#send or something else?
	recv.__send__	# probably Object#send but no guarantee
	recv.__send	# same as __send__? or as send? or Object#send?
	recv.__send!	# ????
	recv.class	# is this Object#class? is this for recv
                         # or for an object proxied by recv?
	recv.object_id	# was this overridden?  what about proxies?

I wonder if 1 & 2 might be better addressed via syntax.  Something like:

	recv.m		   # standard dispatch with literal method name
	recv <- :m	   # standard dispatch with dynamic method name
	recv <- :m2, a1    # dynamic method name with arguments
	recv <-(:m2, a1) { #block}  # parens needed with blocks

	recv <<- :p	# standard dispatch with access to private method :p

Currently a standard method (Object#send) is required to access a  
dynamically
named method and that forces the dispatch semantics of the  
Object#send mechanism
to become mingled with the dispatch of the message itself.  That  
isn't the case
with the standard 'dot' dispatch and I think it complicates the  
situation
quite a bit.  By using different syntax for dispatch to dynamically  
named methods
there is no need to worry about Object#send itself being overridden.   
The syntax
I suggested above (<- and <<-) is not special, just a way to  
illustrate the idea.

That still leaves the problem of name clashes and unanticipated  
redefinitions for
things like #class, #object_id, and so on.  Could this be handled by  
providing
a way to override the normal method lookup process?

	(recv, BasicObject).class
	(recv, BasicObject).object_id

Again, the syntax is just a suggestion, but the idea is to force  
Ruby's method lookup
process to begin its search with a particular class, bypassing the  
normal order of
lookups. The two ideas can be combined:

	(recv, BasicObject) <- :class

BasicObject could be frozen so that its methods can't be redefined/ 
undefined.

Regardless of my particular suggestions I think it is helpful to view  
the issues (1,2,3)
separately rather than as a larger indivisible problem.

Gary Wright