From: Brian Takita Date: 2006-01-11T07:35:23+09:00 Subject: Re: Ideas on "Why Living Dangerous can be A Good Thing" in Ruby? ------=_Part_24356_23067941.1136932510619 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline If you like, you can use the method_added callback to see when a class gets updated. For example, putting the following code before your unit tests will give yo= u an indication of where methods are added. Of course it would probably be best to require a file with this code. Of course this doesn't cover everything (like methods being added via eval or changing instance variables), but it seems with better analysis tools an= d libraries, this hole can be covered. See http://weblog.freeopinion.org/articles/2006/01/06/find-out-where-a-method-w= as-added-in-rubyfor more details. # A class like this can be in a library somewhere. This is a rough draft implementation. class MethodDefinitionContainer class << self def instance @instance =3D Hash.new unless defined? @instance @instance end include Enumerable def [](key) key =3D key.to_sym instance[key] end def []=3D(key, value) key =3D key.to_sym instance[key] =3D [] if instance[key].nil? instance[key] << value end def each instance.each do |key, value| yield(key, value) end end end end # End library code class Object def self.method_added(id) MethodDefinitionContainer[self.to_s + '.' + id.to_s] =3D caller[0] end end #### # Unit tests are run here #### sorted_keys =3D MethodDefinitionContainer.instance.keys.sort sorted_keys.each do |key| puts key values =3D MethodDefinitionContainer[key] values.each do |value| puts "\t" + value end end On 1/8/06, gwtmp01@mac.com wrote: > > > 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 > > > > > -- Brian Takita http://weblog.freeopinion.org ------=_Part_24356_23067941.1136932510619--