"Dave Thomas" <Dave / PragmaticProgrammer.com> wrote in message
news:NRib7.15146$5j7.939061 / e420r-atl1.usenetserver.com...
> "MikkelFJ" <mikkelj-anti-spam / post1.dknet.dk> writes:

> So, I'd suggest that coming across this kind of situation, where you
> feel that you need parameter checking, might be a flag to make you
> stop and think. Could I restructure my application to remove the need
> for this? What are the reasons I got into this particular situation?

For some applications this is true. But you might feel comfortable with the
current design but nervous about abuse in special cases that does not
warrant restructuring (or refactoring as the buzzword is these days). In
this case you can catch errors earlier, and state the requirements of the
function more clearly.

It is not necessarily bad application structure. It can be a need for
flexibility, as the following example will show:
I work on a project where we have a common database frontend with plug-ins
for multiple database backends. These backends may or may not support
rollback. One strategy can be to progate in error in the case a rollback
were needed, where operation could otherwise continue if rollback were
supported. In that case we are no worse of than in not testing anything in
the Ruby example. Another strategy could be to try deleting data in order to
return to a consistent state. For single user access this could be fine. We
are using COM with fixed interfaces for backend plug-in, but if say Rollback
is not supported, that method would return a not implemented error. This
corresponds to Ruby failing to execute the Rollback method in the above
example.
In the COM situation, it does not make sense to verify the interface because
it is already known, but it might be "cheating" by not implementing
everything.
So here it is actually necessary to check on a per-method basis for some
operations.
This somehow counters my own argument. I can easily see a situation from
more than one side. But the point is that the check must somehow be done
"early enough" whether it is testing an interface, a flag or a method -
unless total failure is acceptable. Actually we do also have some properties
where the backend tells the frontend what it can do. It may not be telling
the truth. This is equivalent to implementing a null mixin in Ruby. It
certainly is an error to publish behaviour you do not deliver.

In the end, there are as many answers as there are problems. But it requires
careful design considerations to completely ignore interface validation,
when multiple "input-providers" are part of the integral design.

We are dealing with flexible plugins, fault tolerance, avoidance of plain
dumb bugs, etc.

That said, I agree with your original posting. In most cases the best choice
in Ruby is to avoid validation since one kind of error is as good as the
other, and it clutters up the code. If you want to catch type errors early,
you should be using another language like Standard ML. Ruby can't deliver
this, instead it can give very readable code and fast development/test
cycles.

Mikkel