From: Patrick Hurley Date: 2005-12-23T07:30:37+09:00 Subject: Re: Diff of opinion on dynamic stuff On 12/22/05, Bob Hutchison wrote:>> On Dec 22, 2005, at 4:27 PM, Drew Mills wrote:>> > Let me preface this post by saying that I'm no Ruby expert. I like> > it.> > It's fun. But I won't claim extensive knowledge on it.> >> > So when this guy blogs about a Python quality that he feel is better> > than a Ruby quality:> >> > It's the second generation that's going to be less enthused,> > that's going to stare in bafflement at these classes that> > mysteriously spawn methods, and trying to figure out what's> > going when there's an exception in dynamically generated> > code. You can monkeypatch code in Python pretty easily, but we> > look down on it enough that we call it "monkeypatching". In> > Ruby they call it "opening a class" and think it's a cool> > feature. I will assert: we are right, they are wrong.> >> > -- http://blog.ianbicking.org/theres-so-much-more-than-rails.html> >> > I am curious what this means. Is Python against dynamic stuff? And> > Ruby for it? And so we just agree to disagree? Or do I> > misunderstand?>> Well, Python is plenty dynamic. I think he is complaining about> Ruby's ability to re-open a class. This can make it difficult to find> the complete definition of a class (imagine doing this in a> completely random way in multiple files). So while it can be abused,> it can also be an incredible simplification of the code you write.> One thing it does is flattens inheritance hierarchies, you don't> need to introduce specialising classes just to add a few methods.> Using xampl as an illustration: the Ruby version of xampl generates 1> class for every 3 generated by the Java version of xampl, one of> those classes is eliminated because I can re-open classes (the other> is eliminated due to duck typing). Another thing reopening classes> does is, obviously, to allow you to extend the built in Ruby classes> (they are just classes after all). I suppose Ian would think things> even worse because in Ruby you can do this to objects as well as> classes.>> This 'monkeypatching' is very similar to concepts in Smalltalk and> CLOS (Common Lisp's object system). Nobody in those communities> complains too much (though Smalltalk's browser reassembles classes> for you, and new CLOS programmers are sometimes at a bit of a loss> because in CLOS methods may belong to two or more classes and it> doesn't seem that the obvious thing to do is the right thing). Ruby> just makes thing a lot easier.>> Just be careful where you aim that thing.>> Cheers,> Bob>> >> > Just curious.> >> > Drew> >> >>> ----> Bob Hutchison -- blogs at > Recursive Design Inc. -- > Raconteur -- >>>> I think there are two conflated issues here. First open classes andtheir abuse and second dynamic method creation. I think they distinctenough they should be considered separately. Considering open classes, I find many of the conventions used inRails, once they are understood, simplify the resulting code. Giventhis, it is worth pointing out that Rails is fairly unique in Rubydevelopment being a mainstream library that does modify base classes.Additionally very few of the enhancements to the base classes are"non-obvious" even a non-programmer will recognize the purpose ofitem.pluralize. It is arguable and I would not disagree that this isstill thin ice. Using different Ruby libraries may cause issues�itwould be good if such changes could be better scoped. Still inpractice I have encountered none of the sort of problems I have wouldexpected. And unit tests are still the best medicine The second issue of dynamic method generation (which I think was themeat of the above quote) seems more like a documentation issue thananything else. Consider a different framework that used a data file tocode generate a large number of access methods into a database,similar to the functionality which is dynamically generated withinActiveRecord�would this be the monkey patching that is so troubling?Similarly, while it can take some acclimation, who cannot understandcode like: item_list = Item.find_all_upc(upc) Yes, you would look long and hard to find this particular method inthe API, but once the convention is understood (as it should be byanyone who has developed in Rails for more than a day or two) it isvery intuitive. In the end, I think it is a matter of trust. Any programming languageworth using, can be used poorly. Ruby and Python are no exception inthis regard. Writing good code which by definition is maintainablecode by both first and second generation coders is difficult. Railsuses much of the power of the Ruby language to map the code to theproblem domain (database driven web applications). As always the devil is in the details. I would be very curious whichaspects of Ruby/Rails development in particular anyone thinks will bea long term maintenance issue. pth