* Sean O'Dell <sean / celsoft.com> [1144 19:44]:
> A: I don't agree that it helps you control your large team projects.  Can you 
> offer more evidence?
> 
> Q: Okay. We have to look to code quite often in lieu of project documentation, 
> and normally we look to the description of classes, and the declarations of 
> function parameters to determine how to make calls and to understand how 
> classes are designed that are unfamiliar to some of the programmers on the 
> team.  Type checking would help us to know what parameters are used by 
> certain methods at-a-glance, which saves us from having to spend time 
> studying source code to figure things out.

You're assuming the guy who wrote the library methods used this
optional 'interface' extension. If he cant even be bothered to
document his library, why would he do that?  Wouldnt a class
need to know in advance that it would be passed to an interface-aware
method?

	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).

D'd certainly like extensions to respond_to? so I could check argument
type and count (think someone posted that earlier?) - but that could
be mixed in, so I wouldnt be imposing this on those who didnt want it.

> Q: Okay. When an unsuitable object is passed to a method, and that method 
> tries to call a method of the object that either doesn't exist or has a 
> different number of parameters than expected, an error occurs deep inside the 
> method and it's tedious figuring out how to fix what went wrong.  Some form 
> of type checking would help us recognize our mistakes faster.

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

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?

Pass a custom object in that has a method_missing? method that does
a ludicrous amount of debugging of how its called. That would tell you
how an API is actually using your object, what methods it calls and how.

Thats a back of a beermat approach, but I reckon that coupled with
some good unit testing frees you up from relying on the kindness of
strangers, at least a little.
Even if it only tests method name and argument count, that gives you all
an interface would, without any changes to the API you are using.

The difference is API probing can be done with existing mechanisms,
*optionally* and more importantly, they dont require both sides
of the method to play by the rules. Or reach a consensus :)

> Q: Gee, alright, but I'm running out of reasons.
> 
> A: Thus you are close to realizing the friviolity of your request.

[snip]

The pissing contest is getting old now, and its just drawing out a
long thread to a longer one.

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.

-- 
Boling's postulate:
	If you're feeling good, don't worry.  You'll get over it.
Rasputin :: Jack of All Trades - Master of Nuns