From: Robert Dober Date: 2007-10-16T22:25:32+09:00 Subject: Re: nil.to_i returning zero On 10/16/07, Rick DeNatale wrote: > On 10/16/07, Robert Dober wrote: > > On 10/15/07, Rick DeNatale wrote: > ... > > > which would allow sequences like: > > > > > > a ||= 0 > > > a += 1 > > > > > > To be just > > > a += 1 > > > > > > > > > As I said ALMOST ready to go out on a limb, since I haven't spent much > > > time pondering the consequences. > > Please let me help you with this then ;) > > > > The consequences would be that you code gets much more difficult to debug. > Good Rick never good fight with you, always agreed, now we can go for it ;) > I don't know that this is necessarily true. > > I'm not coming up with an example of code which this makes harder to > debug, but that might just be a lack of imagination on my part. Well I always forget to initialize my ivars and I get bitten late, I guess if nil responds to messages it will take me about 10mins longer to find the error (on average) but extreme cases exist :(. > > > Now that is not necessarily a reason not to do it, Thomas just boldly > > said "bah that's what tests are for", this is a respectable POV, I > > however feel that not everybody in this discussion is aware of the > > fragility that may include into the code. > > Personally I would prefer not to pay that price, many are prepared to > > pay it, so they are probably not completely wrong ;). > > What price? Writing tests? Tests are an investment. Test driven > development is what enables writing agile quality code in dynamic > languages. Some would argue that it's a superior replacement for > static typing, and I'd be one of those. Completely agree with you here, that was *not* the prize I was thinking about. I was rather thinking about robustness and readability and *maintainability*. > > > > Let us have some fun with OO now, again that is not an argument for or > > against, I just want to look at it from yet another angle: > > What would one esteem the responsibilities of NilClass ? > > > I just finished KentBeck's Smalltalk Pattern Best Practices and I have > > therefore much > > difficulties to sacrifice "Readability" for "Elegance". But it would > > make programming > > more fun, sure ;). > > Ah, but readability is language dependent. To make an analogy, > Chaucer, Shakespeare, Voltaire, and Hemingway are all readable to > various degrees depending on the reader, and his familiarity with > different language and literature. But they do not mean to be maintained LOL, let us just rewrite Hamlet for our new customer -- wait a minute these things happen too. Yeah readability is relative as in art, but programming is an art.... > > Kent's book is very strongly rooted in Smalltalk and in the > capabilities of the typical Smalltalk IDE (primarily VisualWorks and > VisualAge at the time the book was written). A number of his > patterns deal with doing things which maximize the ability to read the > code using browser facilities. Very true indeed, but that only means we need a Ruby Browser :) > > Pattern's don't live in a vacuum, the choice of patterns is affected > by environmental pressures, and the language is a major contributor to > these pressures. > > I'm pretty sure that Kent would agree with this. Kent's all about > carefully choosing patterns. Yeah but he clearly said it "communicating code" comes first, and I believe that defining all that kind of messages for nil is not in this spirit, but this is a Strong View Weekly Hold (if you see what I mean ;). > > Here's another Kent Beckism, with no intended connection to anything > said on this thread. Yesterday I watched a video of a recent panel > chaired by Martin Fowler on the infoq site. Martin put together a > collection of senior ThoughtWorks consultants to discuss the > relationship of design to agile methods. One gave an example of a > project which got off on the wrong track by making a simplifying > assumption which caused much grief when the app needed to be scaled to > large numbers of concurrent users. > > it was pointed out that this was a counterexample to Kent's "Do the > simplest thing that could possibly work." Martin pointed out that > simplicity often requires a deal of thought. He quoted Kent who in a > similar situation was heard to say, "I didn't say the stupidest thing > that could possibly work!" Well understood but sometimes you just cannot anticipate things and not wasting time by trying is a clever thing, anyway that is not really related I agree. I guess I am against nil.to_i etc. because I tend to abuse of these and want to be proteced (kidding). Cheers R.