On 6/7/04 11:39 AM, "Paul Sanchez" <paul / NOargelSPAMfraster.org> wrote:

> Richard Kilmer wrote:
>> I'm going to chime on this thread in two areas:
>> 
>> 1) [...]
>> 
>> 2) Sean:  It seems like what you are looking for is to check a method for
>> 'semantic equivalence'...that is, you want to say that the [] and []=
>> methods on an object are semantically equivalent to the [] and []= methods
>> on Hash.  Not that the object is in any way (from and inheritance
>> perspective) related to a Hash, nor does it actually get the behavior of a
>> Hash object's []  and []= methods, but when it comes to those two
>> methods...'quack like a Hash'.  Does that sound right?  If so, the question
>> becomes how to express this kind of semantic equivalence both in the
>> definition of the methods, and the checking with respond_to?
>> 
>> -rich
> 
> Rich,
> 
> I've been watching this thread and I think you've hit the nail on the
> head.  Sean seems to want semantic equivalence, but is using a syntax
> which is overloaded out of the box.  Duck typing is based on syntax
> matching.  It seems to me that the only way to get semantic equivalence
> without using type cues or explicit testing is to steer clear of
> overloaded operators and methods, so that syntax reflects semantics.
> This is what several others were suggesting when they talked about using
> hash's alternate method names in place [] and []=.
> 
> --paul

Right...I was thinking...you could add this to Ruby:

class Foo

  def [](key)
    @mymap[key]
  end

  def []=(key, value)
    @mymap[key] = value
  end

  equivalent_method(:[], :[]=, Hash)

end

Then...


f = Foo.new
f.respond_to?(:[], Hash) => true
F.respond_to?(:[], Array) => false

Or something like that...

Moreover, if you could do that syntactically (ie. Change Ruby to support
this kind of thing) like the following (love it or hate it) syntax:

class Foo

  def {Hash}[](key)
    @mymap[key]
  end

  def {Hash}[]=(key, value)
    @mymap[key] = value
  end

end

f = Foo.new
f{Hash}['name']="rich"

...but you don't always need the {...}

p f['name'] => 'rich'

...and if you do something that's naughty...

p f{Array}[1] => raise Exception...

Or something along those lines.  This way, every existing namespace
(module/classes) become 'addressable' for use in semantic descriptions of
methods (both in defining and calling)...and variables still are not 'typed'
in this worldview.  All this stuff is completely optional.

-rich