On Thu, Nov 27, 2008 at 8:27 PM, Mark Wilden <[EMAIL PROTECTED]> wrote: > On Thu, Nov 27, 2008 at 5:12 PM, Brian Takita <[EMAIL PROTECTED]> > wrote: > >> >> I suppose that we can write our entire program with one LOC. I suppose >> thats following YAGNI. Hell, why use do end? Its two extra lines of >> code all over the place. > > That's not YAGNI. :) We need clarity now - there's no 'gonna' about it. I > was responding to the idea that we should always use class << self in case > we need the construct later. Great. That makes sense to me and I agree. Thanks for clarifying. > >> >> >> I think we also like how consistent conventions and delineation of >> >> responsibility make code faster to read and understand. >> > >> > Agreed, but I think this begs the question under discussion. >> I don't follow. Can you clarify? > > I just thought the statement above assumes the issues in contention in order > to bolster its argument. It assumes that using def self.foo is not a > consistent convention and doesn't delineate responsibility. That's not a > given - it's one of the things we're discussing. Ok, I think class << self is more consistent, because you can use the same idioms as in class Foo. You cannot when using def self.method_name. I find that many of Ruby's class stuff (@@ variables, private_class_method, etc) as having to learn more stuff which I don't want to care about.
I'm wondering if this is a discussion about taste. I have my experience with both approaches and you have yours. Just because something works better for you does not mean its going to work better for me and vice versa. I know that using class << self has been very helpful in making my design better and it helps me to understand the code vs the def self.method_name. I see def self.method_name as a useful shortcut in irb or when there are few (0 to many depending on the person and situation) simple methods on the class. There is a point to where it, IMO, makes the code more difficult to understand, though. > > ///ark > > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
