* Sean O'Dell <sean / celsoft.com> [1115 21:15]:

> On Friday 21 November 2003 12:48 pm, Rasputin wrote:

> > * Sean O'Dell <sean / celsoft.com> [1144 19:44]:
> > 	This seems to be using interface implementation to flag a class
> > as suitable for use in a particular way. Thats just as much an agreed
> > protocol between the method and the argument as a respond_to? approach,
> > but respond_to? doesnt require such a fundamental change to the
> > language (and thats what it would have to be, if it was really to be
> > useful - I dont think an optional feature would please anyone).
 
> The difference is: simply stating a class' purpose is easy.  You do it once 
> and that's pretty much it.  As you develop, though, the interface changes.  
> Keeping up with specific method documentation is much more labor-intensive.  
> If you have an interface description that you had to adhere to, you wouldn't 
> have the option of falling behind on updating it.  Your code simply wouldn't 
> work until you did.
 
Right, but thats no different to enforcing a respond_to? and
arity check coupled with an assert. I'm not saying thats a better
way, just it gives you the same assurance (IMO) without
such a big change to the language.

> > But again, its less hassle to document your API than to do rigourous
> > argument checking.

> No, it's more hassle.  To update a document, you have to open a different 
> file, and if you make a typo or just plain write it wrong, there is nothing 
> to stop you from doing so.  Interfaces can be described in the same source 
> file as your class definition, so it's easy to find and update, plus, you 
> can't update it wrong, or your code gives you errors.
 
My main doubt about this is, unless I misunderstand it,
this only makes APIs easier to use if the author decides to
use interface declarations.
	But the choice 'to doc or not to doc' is no different to
'to interface or not to' for a lazy sod (I speak as one myself).
Unless you enforce it across the language, which would get you
burnt at the stake, you've potentially forked the language and you may
not even see a benefit.

	It seems to me that when working around lazy b*stards like
me, its easier to doc a third party library than to retrofit
interfaces onto it.
 
> > It seemed like you were more interested in a way to know how an API
> > will use your object. Why not send in a probe?
> 
> Because probes can sometimes cause damage, and the errors reported deep inside 
> may not be easily understood.  It's a hit-or-miss proposition in there; some 
> people have no trouble diving in and reading someone else's code.  I do it as 
> a last resort because I find it's a terribly inefficient way to debug.

I agree, and I have found several promising APIs unusable because the
documentation was non-existent. My point was there are ways and means in
Ruby that the typed languages dont have, that feel more Rubyish than
a bolt-on feature.
	In this case (investigating an alien object) we can verify an
object passed as an argument( respond_to? and arity checks) has methods
we expect, and callers of our methods can also see how methods they pass in
are being used by us (by use of a probe object).
	I dont think an interface check can do any more. Admittedly someone has
written 'this object is for Xing' on it, but 99% of the time knowing there
is a method doX(objectA,objectB) does that job. There are edge cases
(using RMI systems, etc) but personally I'd prefer to dissect the remote
object rather than trust a flag on it if I didnt trust the source - and if 
I knew where it came from, I'd rather unit test it.

I've started talking personal prefs, so I'll stop posting after this -
thats my 2p, anyway.

> Well, since classes can implement interfaces, the test can also check that 
> methods are being passed object that fulfill the interface contract.  So, a 
> sort of type checking can be performed.

But thats no different from probing the objects you are passed as arguments.
 
> > I think I share some of both sides viewpoint, but I dont want a
> > Java'ed Ruby, and it seems that this interface idea is coming from
> > that angle.

Incihentally, my opposition to this isnt 'not invented here', its simply
that interfaces in Java *increase* flexibility, whereas in Ruby they
seem to be a restriction.

-- 
Truth is the most valuable thing we have -- so let us economize it.
		-- Mark Twain
Rasputin :: Jack of All Trades - Master of Nuns