(original) (raw)

On 06/15/2012 12:18 AM, Nick Coghlan wrote:

Perhaps you meant "ill-concieved"?

No, I mean ill-defined. The criteria for when a particular platform  
should flip that bit for an arbitrary parameter is highly unclear, as  
whether or not a particular parameter is "implemented" or not depends  
on the operation and the parameter.

I guess I really did do a poor job of explaining it then. Here's another pass.

My working definition for "is\_implemented" is "is this functionality available at all?" Pressed to produce a stricter definition, I \*would\* define "is\_implemented" as:

True if it is possible to produce any valid inputs for the parameter on the current platform, and False otherwise.

However, I don't think parameters should be added and removed from a function's signature based on what functionality is available on the local platform--that way lies madness. Instead I think it best to define a no-op default value for every optional parameter, and always accept that even when the functionality behind it isn't locally available. Function signatures should be stable. Therefore I amend the definition to:

True if it is possible to produce any valid non-default inputs for the parameter on the current platform, and False otherwise.

If I understand you correctly, you seem to be trying to apply "is\_implemented" to the problem of predicting which specific inputs to a parameter would be valid. I don't think that problem is tractable--it's way too context-specific.

/arry