struct mixins

div0 div0 at users.sourceforge.net
Mon Nov 16 11:32:57 PST 2009


-----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.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLAajpT9LetA9XoXwRAkDsAKCZ59OTxLlqoKUZFVMkElBOED/ihwCfbBf9
txVFtwPyKxkrYmYHzVeETI4=
=o8VR
-----END PGP SIGNATURE-----



More information about the Digitalmars-d mailing list