gwtmp01 / mac.com wrote:
> 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.

Great observations and well summarized. Thank you!

I like you're '<-' idea. I think you make a very good point about this
being a dynamic dispatch operator.  It did not dawn on me before but it
doesn't make a whole lot of sense to have overridable dyanimic dispatch
but not for literal dispatch. #send should just mean '.'  And I would
suggest that unless #send is going to control all dispatching,
including literal calls, then another operator as you suggest is the
right idea.

The operator you suggest however would probably have to be flipped to
avoid ambiguity with Symbol#@-. Eg. recv < -:class (I know rare. but
possible).

As for the class search idea, that can be done easily enough with:

  recv.as(BasicObject) -> :class

Though is would be better to code #as into core. But I would like to
see a short hand for the BasicObject case. Maybe

  recv ~> :class

To outline, this would give ruby a complete set of dispatch operators:

  .        literal
  <-      dynamic
  <<-      functional (dynamic)
  <~       pervasive (dynamic)

T.