| Aaron Blohowiak on 6 Mar 2008 20:51:01 -0800 |
|
Sounds like East coast vs West Coast to me. :) When you're a jet, you're a jet all the way -- from your first cigarette to your last dyin' day. anyone get the feeling inheritance is getting the short Inheritance isn't the be-all, end-all of code reuse. The classic polymorphism and inheritance diamond problem, for one. For a more Ruby-centric issue with inheritence, consider this:
class X's initialize method takes an optional parameter that effects the behavior of X for the lifetime of the object. class A descends from an anonymous class that Delegate creates from class X. The initialize function of A does some wonky crap and then calls super to instantiate X.
You are designing class B. Class B is supposed to behave just like class A, but with some less wonky crap in initialize. If you monkeypatch A, you cannot use it as it is documented (and, it is a class that is part of the Ruby Standard Library!) If you descend from A, you lose the ability to pass an optional parameter to X's initialize (you cannot call super to the grandparent's without monkeypatching the parent, AFAIK.)
How can you safely modify A such that you have a new class that does what you'd like? The answer isn't inheritance, my boy!
B = A.dup class B def initialize(optional=nil) super(optional) end
end Now, if class A pushed most of its behavior into a module, you could just import that module into B and define initialize as you please. But, it didnt, so you are stuck with this stuff. I call it clonepatching. The downside to this approach is if you are attempting to discover where B's methods are defined using reflection.. it cannot really express its relationship to A (AFAIK, please correct me if you have a solution to this dilemma.)
Cheers! -Aaaaaaaaaaaaaaaaron the poor.
_______________________________________________ To unsubscribe or change your settings, visit: http://lists.phillyonrails.org/mailman/listinfo/talk
|
|