On Tue, Feb 10, 2009 at 11:21 PM, Rick DeNatale [email protected] wrote:
That’s fine unless you want to, say, override the class method in a subclass
Good point, but there is another issue here.
Your project guru comes along and tells you: Nice code, but we should
not use the name Test (for a dumb reason of course).
Now you have to change Test to Check in your source
would you prefer to change it here
class Test
def a # multiply this with n entries
self.class.x
end
def self.a
…
or here
class Test
def a
Test.x
end
def Test.a
end
In other words the second version is not DRY and the worst penalty for
unDRYness is the need to change your code.
I think Object#class is something to be avoided in most cases. Frankly
it’s none of your business what class was used to create an object. It
doesn’t matter how an object sprang into existence, what matters is
how it quacks.
I want to replace an object with a delegate with no ill effects. Or
with a mock object, or with whatever. But uses of Object#class defeat
this.
I would be inclined to make shared data explicit either with a constant
or a with a passed-in reference to the shared data, rather than implicit
with Object#class.
class Test
SHARED = Struct.new(:ctest).new(2)
def itest
puts SHARED.ctest
end
end
Test.new.itest #=> 2
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.