> That's precisely why you don't optimize. If you find you need fast code, you use a different language. Ah, now I get you :) > First, generally you can tell

> That's precisely why you don't optimize. If you find you need fast code, you use a different language. Ah, now I get you :) > First, generally you can tell by looking at a method's code what it's expecting you to pass to it. Here we might differ, I would always prefer to state clearly in the function doc what types of parameter values are allowed. For example, even if you have a really simple little wrapper in javascript: function log(x) {console.log(x);} Without documentation, you have to know what console.log can do for different types. So I'd definitely prefer this: /** * Logs x to console. * @param x a value of a primitive type (other types are not guaranteed to be logged in a readable manner). */ function log(x) {console.log(x);} > A gem will often define its own classes, which you might pass objects of around, (money, phone numbers) these will often be the primary focus of the gem, and how to use these objects will be written right there in the documentation. Yes exactly, it will be documented as any public API should be. I have no problems using opaque types. But a function call(x) which expects x to be some object representation and not any old string (for which the library has constructors, e.g. PhoneNumber(string)) should surely document this, no?