struct mixins

[Leandro Lucarella]

Bill Baxter, el 16 de noviembre a las 13:08 me escribiste:
> On Mon, Nov 16, 2009 at 11:32 AM, div0 <div0 at 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