[#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:03904] Re: require, ensure, and Design by Contract

From: Dave Thomas <Dave@...>
Date: 2000-07-09 21:17:44 UTC
List: ruby-talk #3904
"Hal E. Fulton" <hfulton@austin.rr.com> writes:

> 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.

True, but you _can_ determine:

  1.  all the methods in the current class
  2.  when any methods are _added_ to a module
  3.  the current subclasses of a class
  4.  when a class or module is used to extend another

Using these combinations, I _think_ there's enough power to be able to 
wrap existing methods in pre- and -post condition handlers (where the
post-condition handler also checks the class invariant), and to be
able to perform the wrapping on subclasses when needed. That was the
approach I was considering.

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

The problem I bumped in to here was saving away parameters to the
method being called. For example, in

   
    def incr(n)
      n + 1
    end
    { post: result == n.old + 1 }

I couldn't see a way to determine that 'n' was a parameter. Apart from 
this problem, I agree with Andy that DbC could be added with no
interpreter mods.


Regards


Dave



In This Thread