From: Austin Ziegler Date: 2007-10-09T06:27:12+09:00 Subject: Re: The Case for Multiple-Inheritance On 10/8/07, Trans wrote: > On Oct 8, 9:13 am, MenTaLguY wrote: >> On the other hand, if you're reusing them in multiple places, e.g.: >> >> class FooWithBarAndBaz >> include Foo >> include Bar >> include Baz >> end >> >> class FooWithBarAndHoge >> include Foo >> include Bar >> include Hoge >> end >> >> ...you've got to create a distinct class up front for every >> permutation of features. If you were composing objects instead, you'd >> be able to compose objects dynamically, instead of being limited to >> the particular compositions that you've baked into classes. > How would you do it? Ok, say we create classes for everything instead, > then how do create this dynamic composer? Is it a factory? > > FooWithBarAndHoge = Composer.factory(Foo, Bar, Hoge) > > So what's really that difference between this and the above? Or do you > have something else in mind? Um. class Foo; end foo_with_bar_and_baz = Foo.new foo_with_bar_and_baz.extend(Bar) foo_with_bar_and_baz.extend(Baz) foo_with_bar_and_hoge = Foo.new foo_with_bar_and_hoge.extend(Bar) foo_with_bar_and_hoge.extend(Hoge) David Black has to repeat every so often for new folks that class only implies the starting type of an object, not its type-at-the-moment. > Seems like in the end it's formally equivalent no matter how we do it, > only the underlying implementation differs. Of course there are > different trade-offs to consider for different implementations. But I > doubt any one is better than another in all ways. For instance using > delegation, we initialize four new objects in memory for every one > FooWithBarAndHoge, depending on what's more important to us, that > might not be as desirable. Um. You're confusing delegation and composition again. There's a difference, although composition is necessary for delegation. One does not need to delegate if one composes. One only needs to delegate in an Acts-As situation. The compositional approach has benefits as well, in that you can reuse your objects, not just your class design. >>> Just because your storage representation is flat doesn't mean your >>> in-memory object has to be. >> I've come to recognize a tying of the internal representation to the >> serialized form as a code smell, because usually (especially) when the >> serialized form is designed to be human-editable, the requirements for >> the structure of the two can be very different. > There doesn't need to be just one representation for all cases, does > there? A one-to-one map is great for a first layer. Then an adapter > can be created for any different internal representation that's > needed. But in my case, the whole point of the class is really to > provide read-access to that serialized data. Then why do you bother with a class? Why not just use the deserialized hash? Unless, of course, you're adding methods that manipulate the stored state. If so, then if you're grouping related values together with modules, you're *still* better off using classes and composition instead. [snip] >> Just because your storage representation is flat doesn't mean your >> in-memory object has to be. (And you can define your own #to_yaml on >> the Package class that flattens things for saving.) >> >> This is no different than what I wrote for Ruwiki four years ago (I >> eschewed YAML because Syck was broken in a couple of different >> releases of Ruby.) [snip] > You have thus far claimed that any class with 50 attributes is dumb, > and that you would fire any employee of yours who used modules as I > have suggested. You have also so far shown a delegating form of the > Package class (which is a real production class for me) and have above > given an unfinished rendition of how you'd load it from the YAML > serialization (which is an import human readable part of this classes > purpose). So how about completing the whole thing? Why should I? I'm not interested in working on your project, whatever it is. If I really had time to work on stuff that would become production code, it would be PDF::Writer. Which I don't. Psychological research has suggested that the number of things that most humans can think about simultaneously is limited. The exact limit is unclear and varies from person to person, but I haven't seen anyone that suggests an upper limit higher than twelve or so. Therefore, it will be easier on the developer and the people who use your class to keep your classes conceptually smaller. It's better to layer the classes because then each of those layers is a separate object limiting the number of items that any individual has to think about. > What do you say, Austin? Here's your ruler. -austin -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca