From: Andrew Hunt <andy@...>
Date: 2000-09-13T06:15:03+09:00
Subject: [ruby-talk:4912] Re: [TOY] FL

    >Andy wrote:
    >> I wrote a DBC implementation a few weeks ago, but was waiting until
    >
    >Great! Looks really awesome.

Thanks!

    >Few questions:
    >
    >>   def alpha(x)
    >>     post { DBC.result * 2 == x }
    >
    >Is there any concurrency issues with DBC.result?

More than likely.  As I said, I wasn't *exactly* ready to
release to the world yet.  Actually, I like the idea of passing
result as a paramter to the code block; that would get around
a few problems while only causing a few new ones :-)

    >> The invariant should be the last method defined in a class.
    >
    >Indicating that something "ugly" is being done when invariant is defined.
    
I don't think that's really true anymore -- at least, I just tried
a case where the invariant is defined first and it seemed to work :-)

You can add methods dynamically and they'll play well in DBC land;
the whole game is based on hooking method creation and rewriting methods
as they are added.

    >>   check "Descriptive string" { code block }
    >
    >Where does this write the output? To DBC.check_output_stream, which points
    >to $stderr by default?

If I remember rightly, it uses the string as an argument to the
newly created exception.  I would never presume to spray noise
to standard out, by any name :-)

    >> Once an exception has been raised from an object, that object should
    >> not be considered viable any more.  In particular, it may not detect
    >
    >Nice. Promotes not-too-general-exception-catching, so one shouldn't write
    
Exactly.  An assertion failure needs to be considered deadly. In fact,
I don't subclass the DBC exceptions under StandardError, so a plain
rescue won't catch them anyway.  
    
    >> By default, DBC is enabled with full checking.  To change the checks
    >
    >Again nice. But is there a way for partioning checks? Like that this part of
    >the code uses DBC enabled like this, and that other part doesn't use at all
    >for performance reasons (even while it's built with DBC).

There isn't now, but there could be.  Per class or per object checking
is certainly possible.

    >Any chance to get different versions of DBCs (it seems everyone is doing
    >their own these days :) to different parts of the code?

Probably not.  Once my version is in it starts rewriting any class
that needs it :-)

    >Just a joke, but couldn't help. When we want to say enable invariant and
    >post-condition checking we actually say DBC.enable(DBC::INV | DBC::PRE) :).

Then I made a typo somewhere - to enable invariant and post
one should say "enable INV | POST".

    >> dbc.rb must be able to find and parse the source code, so you
    >
    >Maybe there could be ways to provide the source even when evalling (for
    >piping I don't know).

I discovered a trick to get around that at some point, now if I
can just find the PostIt note I wrote it on...

    >Do you have any idea what's the cost? I guess that your way is quite
    >streamlined as you probably just include that extra code which have to be
    >there, so there're no runtime checks for what we should check *each* time
    >there's a method call.

It really depends on complexity of the invariant.  A simple one is 
no big deal, a complex one may well kill you dead.

/\ndy

--
Andrew Hunt, The Pragmatic Programmers, LLC.
Innovative Object-Oriented Software Development
web:   http://www.pragmaticprogrammer.com   email: andy@pragmaticprogrammer.com
--
Books by Andrew Hunt and David Thomas:
    "The Pragmatic Programmer" (Addison-Wesley 2000)
    "Programming Ruby" (Addison-Wesley 2001)
--