Re: Multiple Inheritence (Was: Is _objc_flush_caches_(Class) necessary to swizzle methods?)
Re: Multiple Inheritence (Was: Is _objc_flush_caches_(Class) necessary to swizzle methods?)
- Subject: Re: Multiple Inheritence (Was: Is _objc_flush_caches_(Class) necessary to swizzle methods?)
- From: DumberThanDanQuayle <email@hidden>
- Date: Sat, 25 Sep 2004 23:08:34 -0400
On Sep 25, 2004, at 9:29 PM, Ondra Cada wrote:
On 26.9.2004, at 3:01, DumberThanDanQuayle wrote:
To change somewhat the behaviour in future without recompilation (using techniques like poseAsClassing or categories) would be quite on the ugly side.
Specifically, why do you think think that using "#include" method implementations would lead to problems when using poseAsClass or categories without recompiling?
For you would have the same code in umpteen different classes: to change or fix it runtime, you'll have to add same poses/categories for them all. Forget one, and you'll wonder what the H is happening, since some code once works and another time "the very same code" does not :)
Ondra, I still do not understand what the problem you trying to describe is nor the real source of it since you also seem to state the "#include" code would is same as normal code. Nevertheless, I want to end this discussion. Since I never dynamically add categories at runtime or have every had the need to "+poseAsClass," which merely lets a class appear to be it's super, I do not consider whatever you are alluding to be a "serious" drawback to the use this technique for weak Multiple Inheritance. To extent that you are stating the that potential problem will be that of confusion about inconsistencies by selectively modifying class that previously behaved identically, the same is true about subclassing in general. Furthermore, this type of inconsistent behavior is exactly the problem being solved here. Clearly, having what is supposed to be identical code, only in one place explicitly avoids that problem.
Now, when I encounter a bug in an uninherited code block that is used by multiple classes, such as when implementing a protocol, I do not have to keep track to what changes I have made as the bug is solved, then search my source code for what are suppose to be identical methods and them modify. This is serious waste of time and does led to inconsistencies due to human errors. Furthermore, using the "#include" I do not even have to make the original copies now by cut pasting. This is huge improvement in my productivity and the quality of my software. I suspect that others will feel the same way.
On Sep 25, 2004, at 10:36 AM, Ondra Cada wrote:
Anyway, in such a situation, I would indeed first consider re-factoring, for the sole fact you need *the same implementation* (unlike the same interface) for intrinsically different classes kind of hints the hierarchy might be flawed. It looks somewhat like you may be using the class hierarchy for something another feature (formal protocol, embedding&forwarding, class clusters, whatever) would serve better, with the result of the hierarchy lacking where you would need it :)
If it is not so, well, as I've already written, I would find a common ancestor and implement the functionality using a category there. Or perhaps I would follow Tor Manders' advice, or use a combination of them.
I suspect part of the real issue here is the esoteric nature of Obj-C / Cocoa. This programming system makes very strong use of certain design patterns and strong Multiple Inheritance obviously is not one of them. It appears to me that this has lead to a sort of dogma among some Cocoa scholars, including yourself, that Multiple Inheritance is a "bad" pattern. The archives are full of such philosophical discussions about the trade-offs made in Cocoa's patterns. Nevertheless, collectively the community seems to focus on graphical applications which is what Cocoa is great for and why I use it. But underneath my GUI is a complex analytical architecture that is fully extensible. The patterns are best to use here are not necessary the same as those for graphical applications, where message-passing paradigm appears to work well.
Your suggesting of "re-factoring." which I take to mean redesigning the relationships between my objects in a fundamental way (and is used as a "red herring" to avoid the real issue of how to achieve some kind of Multiple Inheritence in Obj-C), would continue to require additional "re-factoring" as my software is extended to different applications. Ultimately, this "re-factoring" is asking for the perfect design to a set of unforeseen problems to extensions of my software that I have will not make for years. Even if I had a complete description of the problem I was trying to solve with my code, there would be no algorithm known to generate the correct or best object structure for it. Likewise, Cocoa itself or any design is necessarily imperfect. In terms of mathematics, these questions fall under Graph Theory and would certainly be labeled as "NP-Complete" problems. So, not only is "re-factoring" unrealistic for complex software at an advanced stage of development, it actually may be impossible. This is why people keep on asking for a way a to do Multiple Inheritance in Cocoa and now hopefully they will have one, I know I do.
Truly yours,
George
<x-tad-bigger>"Recession means that people's incomes, at the employer level, are going down, basically, relative to costs, people are getting laid off."
George W. Bush
—Washington, D.C., Feb. 19, 2004</x-tad-bigger>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden