From: Trans Date: 2007-10-08T02:04:29+09:00 Subject: Re: The Case for Multiple-Inheritance On Oct 7, 8:42 am, "Austin Ziegler" wrote: > No, actually, it doesn't provide maximum code reusability. Ruby supports > a rich vocabulary and you're choosing to use a form that, while clearly > useful in some cases, is not right. Yes it does, b/c if methods are placed in a class, the only reuse if via a subclass. If they are in a module they are not limited by that constraint. I haven't lost anything at all by putting all behavior in modules, I have only gained. The approach is a superset. I seem to be the only one who ever gives code examples. How about you show me an example of how you'd do it? > Modules in Ruby are useful for adding new "generic" class capabilities. > > Enumerable is a way of using the ability to iterate over a collection > object (and a collection is defined by #each, which goes through the > *state values* of the object in turn). It's like a Java interface except > that you don't need to reimplement each and every piece of the interface > because the interface is always expressed in terms of #each. > > Transaction::Simple is a way of adding "extra" state to an object that > allows it to be versioned in memory. All of that extra state is managed > by the methods defined in the module. > > What you're talking about is on par with components and graphical > development. They can work in simple cases, but the moment you start > having complex cases, you start realizing that the code is becoming a > bit more complex to integrate that way. You can either refactor your > code, or start looking at ways that the language can change to > accomodate your model's inflexibility. > > Modules aren't really meant for providing state that the object depends > on normally. They're *extra*. So you should be working with classes that > have implementations; you should re-factor out common functionality (and > I mean REALLY common functionality) into modules; you should have a > class hierarchy if it's appropriate; you should compose multiple objects > into a single object where appropriate. You are constraining the use of modules according to your own view of how they "should" be used, and in the process I think you're missing my point. You've created an artificial separation between forms of code encapsulation because, you reason to yourself, one is for handling state and one if for generic capabilities. But that is putting a hard line in a soft world. There really is no need to make that hard distinction. If a coder, like yourself, wants to do that you can do so just as easily with a single form of encapsulation. However the world is not always so clear cut. Modules sometimes deal with state. If we were to follow your logic all the way through, then modules shouldn't be allowed to address state at all. Would we want that? But if we follow my logic all the way through, we have lost nothing. We have only gained. Whether someone else avoids it or shoots themselves in the foot with it is their own problem. I see very good ways to put the new capabilities to elegant use. What we're talking about here ultimately is just a matter of coupling between components. You don't think modules should have anything to do with this and that we should all be using classes and composition instead b/c it doesn't couple the components as tightly together. But I think that's incorrect. Modules are a perfectly valid way of creating components, and coupling behaviors. As along as you avoid shared state (and by that I mean specifically instance vars) then the coupling is being managed quite well. The trade off is just a matter of managing a greater potential for method name clashes, but you save yourself the complexities of method routing. You pick your poison and I'll pick mine. In the mean time your insistence on it being your way or no way is really unfortunate. You might not agree with my techniques but why are you trying to stop me from doing it? Hey, I'm all "Burger King" here! > I'll put it clearly: if I were running a Ruby consultancy and a > programmer of mine used your methodology for everything (e.g., classes > defined by composing modules), I would not keep that programmer on. It's > a bad style. Sorry. Clearly there is a reason you aren't running a consultancy. T.