Re: struct mixins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Baxter wrote: On Mon, Nov 16, 2009 at 11:32 AM, div0 d...@users.sourceforge.net wrote: snip 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 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. --bb Well at the moment you only get one alias this. I suppose you could allow multiple alias this, but then what happens with multiple symbols with the same name? At least with mixins you can disambiguate. Still using member vars worked for me; there's more important stuff to be doing at the moment. - -- 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/ iD8DBQFLAvMpT9LetA9XoXwRAuIZAKCyRCfzrXGEPJeH7n1zC/UcrHvsKACdFX8F qp4lpEqHtf0ruF0XSHVQUXM= =2zvO -END PGP SIGNATURE-
Re: struct mixins
On Tue, Nov 17, 2009 at 11:02 AM, div0 d...@users.sourceforge.net wrote: 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. --bb Well at the moment you only get one alias this. I suppose you could allow multiple alias this, but then what happens with multiple symbols with the same name? At least with mixins you can disambiguate. I don't see why you couldn't allow alias this to give you the same disambiguation capability. Or just get rid of alias this in favor of type mixins. Doesn't really matter to me. But I'm not seeing any reason to have both constructs when they do almost the same thing. --bb
struct mixins
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.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
El techo de mi cuarto lleno de universos
Re: struct mixins
On Mon, 16 Nov 2009 10:32:31 -0500, Leandro Lucarella llu...@gmail.com wrote: What if one could use a struct directly with mixin? This is a very good idea. BTW, I think conflicts should be a compile-time error. -Steve
Re: struct mixins
Reminds me of an older thread: http://www.digitalmars.com/d/archives/digitalmars/D/Implicit_castable_structs_64764.html
Re: struct mixins
On Mon, 16 Nov 2009 18:58:42 +0300, Frank Benoit
keinfarb...@googlemail.com wrote:
Reminds me of an older thread:
http://www.digitalmars.com/d/archives/digitalmars/D/Implicit_castable_structs_64764.html
I recall it, but I still think alias this is the way to go:
struct GtkWidget{ /* data member */ }
struct GtkContainer{
GtkWidget widget; // mixin GtkWidget; could also work, though
// more data members
alias this widget; // how would you do the same without a named mixin?
// And what's the benefit of named mixin over plain old aggregation?
}
Re: struct mixins
Frank Benoit, el 16 de noviembre a las 16:58 me escribiste:
Reminds me of an older thread:
http://www.digitalmars.com/d/archives/digitalmars/D/Implicit_castable_structs_64764.html
I think mixin can mix very well with that proposal, when the compiler sees
a struct mixin, it can automatically provide an {im,ex}plicit cast to the
mixed in type, adjusting the pointer:
struct A {
int x;
}
struct B {
int y;
}
struct C {
mixin A;
mixin B;
}
C* c = new C;
A* a = cast(A*) c; // points to c
B* a = cast(B*) c; // points to c + A.sizeof
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Cómo ser inconmensurablemente atractivo a la mujer del sexo opuesto.
-- Libro de autoayuda de Hector Mesina.
Re: struct mixins
Denis Koroskin, el 16 de noviembre a las 19:03 me escribiste:
On Mon, 16 Nov 2009 18:58:42 +0300, Frank Benoit
keinfarb...@googlemail.com wrote:
Reminds me of an older thread:
http://www.digitalmars.com/d/archives/digitalmars/D/Implicit_castable_structs_64764.html
I recall it, but I still think alias this is the way to go:
struct GtkWidget{ /* data member */ }
struct GtkContainer{
GtkWidget widget; // mixin GtkWidget; could also work, though
// more data members
alias this widget; // how would you do the same without a named mixin?
// And what's the benefit of named mixin over plain old aggregation?
}
See how a struct mixin could add an implicit/explicit cast to the mixed in
structs.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Con vos hay pica, patovica!
-- Sidharta Kiwi
Re: struct mixins
Steven Schveighoffer, el 16 de noviembre a las 10:44 me escribiste:
On Mon, 16 Nov 2009 10:32:31 -0500, Leandro Lucarella
llu...@gmail.com wrote:
What if one could use a struct directly with mixin?
This is a very good idea. BTW, I think conflicts should be a
compile-time error.
I think compile-time error is nice and clean, but you are lost if you're
using a third-party struct, and the maintainer adds a new field that
collides with yours.
Example:
struct ThirdParty {
int x;
}
struct Mine {
mixin ThirdParty;
int y;
}
void myCode(Mine m) {
m.y = 1;
}
If ThirdParty is changed like this:
struct ThirdParty {
int x;
int y;
}
Then your code don't compile anymore and you can't fix it. Either you stop
using mixin ThirdParty or you have to change your struct and *all* the
code written for it.
On the other hand, if you allow explicit disambiguation, you code still
compiles and work as expected. You just won't use the new y variable from
ThirdParty (you didn't use it before either, so that's OK). If you need to
start using the new y attribute from ThirdParty, you can do it with:
void myCode(Mine m) {
m.y = m.ThirdParty.y;
}
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Yeah, I'm a great quitter. It's one of the few things I do well. I come from a
long line of quitters. My father was a quitter, my grandfather was a quitter...
I was raised to give up.
-- George Constanza
Re: struct mixins
-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-
Re: struct mixins
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 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.
--bb
Re: struct mixins
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.Darticle_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
