From: Glenn Parker Date: 2005-06-02T01:58:00+09:00 Subject: Re: array of object insert polices Robert Klemme wrote: > > There's probably a misunderstanding: you seem to talk about internal type > checking for which I completely agree to you. But dave was talking about > external data here IMHO. And it's generally considered good practice to > check data entered by users or coming into an application via other > external sources to make the application robust. Good practice should be a guideline, not a mantra. There are good reasons for checking external data, but they don't always apply, and checking every argument to every function on every invokation can be a real waste. Sometimes you want to give a caller immediate feedback about an input error, but sometimes you may be happy to let them proceed, allowing the *possibility* of failure later on. Actual failure may depend very much on exactly what the caller chooses to do and what kind of objects they provide. With duck-typing, there is always a fair chance that some portion of your API may peform properly, even with objects that were never anticipated. For example, I might insert Integer-like objects, that do not support "<=>", into an IntegerArray object. As long as I don't rely on some kind of "sort_members" method, it seems like I should be OK. When argument testing really is necessary, a compromise is to offer the testing function to the caller as a separate utility. That way, callers can test their input when they think it is necessary, but skip the test when they know it isn't. This also allows the caller to push past the limits of your original API design by using arguments that satisfy the necessary subset of duck-typing for some subset of your API, even if they can't pass the full argument testing predicate. -- Glenn Parker | glenn.parker-AT-comcast.net |