From: Maurice Codik Date: 2006-02-09T00:44:07+09:00 Subject: Re: Meta-Meta-Programming ------=_Part_3371_33354180.1139413432008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I dont really understand why the reaction to this is so negative-- design b= y contract can be a very useful tool (even if the code presented in thir thread is a very limited implementation of DBC). Methods usually spend a few lines of code validating their arguments, especially if they are intended to be used by external clients. Your documentation should definately explain what type of arguments your methods expect-- and your code should make sure that its users are providing the correct kind of arguments. You want to error ASAP if you are given a bad argument. From a user's perspective, a "bad argument" error thrown at the library boundary is much easier to debug than a strange NoMethodError throw= n deep inside your library. Libraries like these just make argument validation a little more DRY (ex, define your contract once, apply it to many methods). It is not just static typing-- the library I wrote, for example, lets you provide Procs to check contracts, so you can test more dynamic/runtime properties such as "this database connection is open." Performance cost? If you are going to be validating the parameters to your methods anyway (which you should), there is very little additional overhead= . Maurice On 2/8/06, Austin Ziegler wrote: > > On 08/02/06, vidar.hokstad@gmail.com wrote: > > Daniel Nugent wrote: > >> Vidar, I think the question there is: Should I rely on a type/method > >> check to ensure that I don't get bad parameters or should I just > >> write some tests to make sure that the code in question fails in a > >> sensible way when those expectations aren't met. Those would be edge > >> cases after all, and you'd have to write the tests for them anyway. > >> > >> To me, it seems to be unDRY... > > > > To me the issue is to avoid surprises. If your function will need a > > specific method every few million times it is executed, or on specific > > dates, or when a specific race condition occurs, or when processing > > specific user input, it might require a lot of work for a user of your > > code to verify that their application works as expected through > > testing unless they know exactly what they need to test for. > > That's what documentation is for. > > > More importantly: Unless _they_ verify these preconditions in their > > test cases they will have to handle whatever you consider a "sensible > > way of failing". If your failure mode doesn't match their > > expectations, it might take a lot of work to set verify that there is > > actually a problem, and it can easily slip through. > > That's what documentation is for. > > > This is a pragmatic way of ensuring the least possibility of surprise, > > by forcing a failure as early as possible. The other alternative is to > > document these cases painstakingly and depend on the users of your > > code to test for them. But why put your users through that pain if you > > have an easy way of trapping the error early on that at the same time > > serves as explicit documentation of what your code expects? > > Except that contract enforcement is *expensive*, and most contracts are > much more difficult to express than can be expressed in the way that > people who are (foolishly) comforted by static typing expect. > > -austin > -- > Austin Ziegler * halostatue@gmail.com > * Alternate: austin@halostatue.ca > > ------=_Part_3371_33354180.1139413432008--