On Tue, Nov 25, 2008 at 8:41 AM, Matt Wynne <[EMAIL PROTECTED]> wrote: > Sorry, I know this is off-topic, but I'd really like to know what the > revered ruby-hackers who read this list think. > > See > http://ozmm.org/posts/class__self_is_harmful.html > > I have adopted class << self, partly from reading RSpec and Cucumber's code > as I learn Ruby. I personally think of class methods (or 'static' methods) > as being in a kind of 'holding pen' waiting to be factored off onto a proper > class of their own, so I rather like the clear way you can group them in a > 'nameless' metaclass ready for the exit door. > > I also really like the clarity of seeing the invisible metaclass for what it > is. > > What do people think? How can this be harmful? Its funny because I consider def self.foo harmful for a few reasons.
def self.method_name is often mixed with instance methods. This makes reading the code confusing because there are two contexts that you need to deal with. Its too easy to confuse because it reads like its in the same instance, def self.foobar @foobar end def foobar @foobar end Also, like you mentioned, using def self. obfuscates an object extraction that needs to happen. With class << self, I can think about refactoring an object, rather than refactoring class methods. class << self allows me to think of class/modules in a more object oriented way. class Foo def self.method_1(an_instance) end def method_1 end def method_2 end def method_3 end def self.method_2(an_instance) end end I also like how all of the class << self methods are organized into a single section. Yes, its difficult to read if it takes more than a screenful, but I prefer it to having to track down all of the def self.method_name methods spread all over the place. Also, class << self is more powerful. It allows you to use one way to use your convenience methods (attr_*, include) and parser instructions (public, private, protected). Nothing is worse than having to use both def self.method_name and class << self. > > cheers, > Matt > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
