From: gwtmp01@...
Date: 2006-01-09T00:00:47+09:00
Subject: Re: Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?


On Jan 8, 2006, at 2:40 AM, Gregory Brown wrote:
> Though it is understandable that the fact
> that the behavior of your software can change quite drastically once
> it's out of your hands in Ruby moreso than some other languages, this
> boils down to good practice and responsibility.  If you're opening up
> a class and adding / removing some code, it's your responsibility to
> ensure it doesn't break things.

One of the things I really liked about Bertrand Meyer's _Object Oriented
Software Engineering_ was his 'programming by contract' point of view.
I've found that concept to be useful in almost any program I've written
after reading that book regardless of the language I've used.

One of the most useful ideas is the notion that if client code
refuses to adhere to the pre-conditions then all bets are off and the
library code has no responsibility to ensure correct behavior.

To a certain extent I think the concerns that static people have about
Ruby seem to be concerns about what happens if they violate the contract
by not ensuring the pre-conditions *at run-time*.  The response  
should be:
Why is that my problem?  The water is under the bridge at that point.  
Game over.

More important is answering:
	How can I discover the pre-conditions associated with Ruby code
	How can I avoid writing code that breaks the pre-conditions?
	How can I determine the post-conditions?

So if there are valid criticism of the Ruby approach I think it could  
be said
that often times the pre-conditions (and post-conditions) are not  
documented
very well (especially with regard to meta-programming).

Documentation can help but I think there is room for language  
features in this
area also (e.g. structured annotations).  Namespaces will also
help to localize effects and provide a framework for describing those  
effects.

Quick Question:  What core classes are modified by ActiveRecord or Og?
Quick Answer: Lots but good luck finding a concise description.


Gary Wright