Bill Baxter, el 16 de noviembre a las 13:08 me escribiste: > On Mon, Nov 16, 2009 at 11:32 AM, div0 <d...@users.sourceforge.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Leandro Lucarella wrote: > >> struct inheritance never make it into D, for a good reason: structs are > >> not supposed to be polymorphic and inheritance is very tied to > >> polymorphism. But struct inheritance is sometimes very useful for > >> "composition", avoid an extra member when accessing to the composed type > >> members. > >> > >> Example: > >> > >> struct A { > >> int x; > >> int y; > >> } > >> > >> struct B { > >> A a; > >> int z; > >> } > >> > >> B b; > >> b.a.x = 5; > >> > >> A way to "fix" this is using template mixins: > >> > >> template Common() { > >> int x; > >> int y; > >> } > >> > >> struct A { > >> mixin Common; > >> } > >> > >> struct B { > >> mixin Common; > >> int z; > >> } > >> > >> B b; > >> b.x = 5; > >> > >> But one can think this is even worse than the previous approach :) > >> > >> What if one could use a struct directly with mixin? > >> > >> struct A { > >> int x; > >> int y; > >> } > >> > >> struct B { > >> mixin A; > >> int z; > >> } > >> > >> B b; > >> b.x = 5; > >> > >> > >> I think this is nice, looks good, is backwards compatible, it might be > >> easy to implement (not sure about that though) and can be even extended to > >> classes (not sure about the usefulness of that either). > >> > >> The only problem are name collisions, but that can already happen with > >> template mixins, right? Anyway, collisions can yield a compile error, or > >> they might be accepted, requiring the full qualified name to access the > >> attribute, like with classes and inheritance (you can't do a mixin of the > >> same struct twice). Say A is updated in the future: > >> > >> struct A { > >> int x; > >> int y; > >> int z; > >> } > >> > >> b.z = 1; // changes B.z > >> // to modify B.A.z: > >> b.A.z = 1; > >> > >> > >> I think collisions should be very rare anyways in structs. > >> > >> PS: For those who wonder, yes, this is inspired in the "embedding" feature > >> of Google's Go, which is basically a mixin, but without adding > >> template to the mix, it's just this, struct mixins. > >> > >> > > > > vote++ > > > > I was going to suggest it when I finished my spirit port, but I was > > too lazy to in the end. > > > > It would be very handy as currently the only way support multiple > > policies is to use member vars which are basically pointers to empty > > classes, so it looks rather more ugly than it needs to be. > > > > Mixin should really go hog wild I think and let you mixin anything anywhere. > > > I have wanted this kind of thing before too. I can't recall the > exact reason, but it had something to do with traits structs. I hit > it when I was porting OpenMesh to D. > > There's some base set of traits provided by the library as a struct > that you may want to add too in user code. > > But I think "alias this" would probably serve that need just fine. > What use cases are served by the mixin that 'alias this' does not? > It looks like this was an attempt to explain, but I don't understand: > "See how a struct mixin could add an implicit/explicit cast to the > mixed in structs."
I meant to say: "See how a struct mixin could add an implicit/explicit cast to the mixed in structs in my previous mail." Which would be: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101242 Maybe I don't fully understand alias this. Does alias this can do that? > I guess mixin struct could allow a kind of static multiple > inheritance. But if that's desirable, then probably alias this should > just be extended to enable that. Seems like the two are so similar > that whatever alias this lacks in features could just be added rather > than introducing a new construct. I really didn't thought about alias this when making this proposal (I had this problem using D1, I'm not using D2 much), so maybe you are right. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- EL "PITUFO ENRIQUE" LLEGO A LA BAILANTA -- Crónica TV