[#3986] Re: Principle of least effort -- another Ruby virtue. — Andrew Hunt <andy@...>

> Principle of Least Effort.

14 messages 2000/07/14

[#4043] What are you using Ruby for? — Dave Thomas <Dave@...>

16 messages 2000/07/16

[#4139] Facilitating Ruby self-propagation with the rig-it autopolymorph application. — Conrad Schneiker <schneik@...>

Hi,

11 messages 2000/07/20

[ruby-talk:03905] Re: require, ensure, and Design by Contract

From: pschoenb@... (Patrick Schoenbach)
Date: 2000-07-09 21:24:35 UTC
List: ruby-talk #3905
On Sun, 9 Jul 2000 14:36:44 -0700,
Hal E. Fulton <hfulton@austin.rr.com> wrote:

>I'd like to have an implementation that puts as
>little burden on the programmer as possible.
>Therefore I'm shying away from what I'm looking
>at right now: An implementation that requires the
>programmer to define two other methods for each
>method for which he wants to check pre- and post-
>conditions.

Agreed.

>I thought there might be some way to generate
>these on the fly, at the time the "pre" function was
>called, for instance. But there is no way to determine
>the class or object of the method that called you.

This is a problem, yes.

>But I have been thinking of a syntax something like
>this:
>
>   pre("positive:x>0  empty:arr.size==0  old.somevar")
>   # ...
>   post("nonempty:arr.size>0  incr:somevar=old.somevar+1")

I quite dont like the fact that you write the assertions "horizontally".
It is quite hard to read. I would prefer a  "pre" statement and then
list all assertions, one per line. This would be more readable.

>The "label:" notation would provide a mnemonic for the
>error message. (Doesn't Eiffel provide this?)

Yes it does.

>The "old.somevar" notation would be a signal to save off the
>value of somevar so that it could be checked at the end.

Basically, I agree. But I do not like "old" has to be mentioned in
"pre". This only would cause stupid ommission errors.

>This is all extremely half-baked, though. Inheritance is the real
>issue: We have to make sure that contracts are heritable.

..and we need something to make the programmer aware of that he is
weakening preconditions/strengthening postconditions in a subclass. In
Eiffel, this is done by enforcing "require else" and "ensure then" in a
subclass for adding assertions.

-- 
Best regards,
Patrick

-- 
---------------------------------------------------------------------------
            	  e-mail: pschoenb@solidsoft.iksys.de
                  URL: http://www.geocities.com/Vienna/5357/
 PGP Public Key: Mail to pgp@solidsoft.iksys.de with 'pschoenb' as subject
     Fingerprint: 3C FB B0 A7 E2 C2 3B 2D  68 6C 66 7E B7 D5 C2 70
---------------------------------------------------------------------------

In This Thread