From: Sean O'Dell <sean@...>
Date: 2004-06-09T06:13:29+09:00
Subject: Re: [ANN] Ruby/Interface

On Tuesday 08 June 2004 13:23, Mauricio Fern�ndez wrote:
> On Wed, Jun 09, 2004 at 03:46:30AM +0900, Sean O'Dell wrote:
> > Ruby/Interface tries to solve this problem by ???tagging??? objects as
> > implementing an interface. The implementation is enforced by comparing an
> > object???s methods against the methods expected by the interface.
>
> Some comments:
>
> I see you're using per-class tagging, hence being unable to track
> changes in the singleton class. I'd point you again to the last sections
> of http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/102555
> which I believe you didn't read.

Per-class tagging is what I intended.  There are three tag states: not tagged, 
tagged but unverified, and tagged and verified.  Tagging initially only means 
"objects of this class may implement this interface."  A check of the object 
itself later will determine if the object really does implement the 
interface.

> There's an inconsistency in the code: you're checking the methods of the
> object (including its singleton methods) with Object#method but storing
> the result in a per-class structure; that won't fly.

I see what you mean.  I need to move the storage of the checks themselves to 
the object, absolutely correct.  I think what I was thinking when I did it 
this way was, since I get no "module_added" messages when methods are added 
to objects with <<, there was no sense in storing the information with the 
objects themselves.  But I see that there's an inconsistency that way.  I'll 
change that.

> Also, using class variables instead of class instance variables ties the
> notion of interface to inheritance, which I believe you wanted to avoid.

No, not necessarily.  Classes derived from other classes should inherit the 
interface.  The initial tag only means "may implement the interface" not 
"does implement it."  The final test is a comparison of the methods of the 
individual object methods and their arity.

> I would consider storing the conformance information in
> ROBJECT(self)->klass directly; this will be either the real class or
> the singleton class. In the first case, the "conformity table" is
> shared by all objects of that class; in the second, it will be "owned"
> by the object. The advantage is that this new table would be created
> on demand, only when the object is extended/a singleton method is
> defined and has_interface? is called. You wouldn't even need to capture
> singleton_method_added this way.

Ah, I see...thanks for pointing me at this.  I was never really aware of klass 
before.  I just read about how it relates to Singleton's, and it gave a whole 
heap of ideas on how I could do this better.

	Sean O'Dell

	Sean O'Dell