Hi --

On Tue, 8 Jun 2004, Richard Kilmer wrote:

> On 6/7/04 7:37 PM, "Jim Weirich" <jim / weirichhouse.org> wrote:
> 
> >>>> Maybe:
> >>>> 
> >>>>  f<Array>['rich']
> >>>>  f.<Person>[firstname]
> >>>> 
> >>>> It's ugly enough to discourage its use, but it also calls
> >>> to mind the
> > 
> > I missed what this syntax (and the other proposals) is supposed to
> > accomplish and the threading in this topic thread is wonky enough so
> > that I can't find the parent messages.  Could someone fill me in.
> 
> The key is expressing that a method you are defining is semantically
> equivalent to a method in another class/module.

It's interesting; I'm actually having trouble coming up with much in
the way of components of Ruby method semantics.  There's number of
arguments... but I'm not sure I can think of anything else.  Arguments
are untyped and methods don't have a return type, and whether or not a
method requires a block (another candidate criterion) might depend on
what happens at runtime.  So in determining whether two methods are or
are not semantically equivalent (and I assume this has to be
determined statically), what else is there, besides argument count,
that one can compare?

Meanwhile, in spite of this rather large question mark, let me delve
into the syntax stuff, just for fun :-) (See below....)

> Contrived example:
> 
> class NameList
>   def initialize
>     @list = []
>   end
>   def first_name
>     @list.first
>   end
> end
> 
> class Person
>   attr_reader :first_name
> end
> 
> class Robot
>   def <Person>first_name
>     @first_name
>   end
> end
> 
> This says that Robot's first_name method is semantically equivalent to
> Person's first_name method (with all that that semantics carries with
> it...which may be a lot, and may not be much).  You can "cast" the method
> call to an instance:
> 
> r = Robot.new
> 
> Like this:
> 
> r.<Person>first_name
> 
> But if you did this:
> 
> r.<NameList>first_name
> 
> It would raise an exception.

I wonder if there's a way to build more organically on the existing
module mechanism, even if more restrictively.  For example:

  module X
    def m
      # ...
    end
  end

  class A
    include X    # A uses X's actual method m
  end

  class B
    emulate X
    def m        # B defines its own method m -- but
      # ...      # 'emulate' has committed it to
    end          # match the semantics of X's methods
  end            # wherever the method names match

  # And per-object (like 'extend'):

  o = Object.new
  o.embody(X)    # commits o to X's methods' semantics,
                 # wherever the names match, but does
                 # not actually give o any new methods
  def o.m
    # ...
  end

It's more restrictive than yours in the sense that with mine, you
can't mix-and-match any method call with any class/module reference.
But I don't think that's necessarily bad, and in any case I wanted to
shoot for something with as much visual smoothness and integration as
I could, while still addressing (some or most of) the same issues.


David

-- 
David A. Black
dblack / wobblini.net