www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - mixins

reply "Walter" <newshound digitalmars.com> writes:
I have this mostly implemented. It's been based on a lot of your
suggestions. The way I did it is, I think, pretty unexplored territory. That
means there may be some pretty cool uses for it I've never thought of. Let
me know what you think, and if I missed the boat completely <g>.

www.digitalmars.com/d/mixin.html
May 16 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Walter wrote:

I have this mostly implemented. It's been based on a lot of your
suggestions. The way I did it is, I think, pretty unexplored territory. That
means there may be some pretty cool uses for it I've never thought of. Let
me know what you think, and if I missed the boat completely <g>.

www.digitalmars.com/d/mixin.html
  
Wow, this is really nice. -- -Anderson: http://badmama.com.au/~anderson/
May 16 2004
prev sibling next sibling parent reply k.inaba <k.inaba_member pathlink.com> writes:
www.digitalmars.com/d/mixin.html
Coooool!! Is it possible to write something like this? : template Foo() {} class Bar(alias Tmpl) { mixin Tmpl; } Bar!(Foo) x; k.inaba
May 16 2004
parent "Walter" <newshound digitalmars.com> writes:
"k.inaba" <k.inaba_member pathlink.com> wrote in message
news:c879v9$15fg$1 digitaldaemon.com...
www.digitalmars.com/d/mixin.html
Coooool!! Is it possible to write something like this? : template Foo() {} class Bar(alias Tmpl) { mixin Tmpl; } Bar!(Foo) x;
Yes <g>.
May 16 2004
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory. That
 means there may be some pretty cool uses for it I've never thought of. Let
 me know what you think, and if I missed the boat completely <g>.
 
 www.digitalmars.com/d/mixin.html
Looks good so far. But two things: First: there is a typo at the top. mixin TemplateIdentifier (! TemplateArgumentList ) ; mixin TemplateIdentifier (! TemplateArgumentList ) MixinIdentifier ; should be (judging from the examples): mixin TemplateIdentifier !( TemplateArgumentList ) ; mixin TemplateIdentifier !( TemplateArgumentList ) MixinIdentifier ; For a moment I thought you'd have to use !( for templates and (! for mixins. I had already started to formulate a flame mail in my head ;). The second thing is a question. Can mixins mix-in other mixins? I.e. template Mix1(T) { void foo(T a) { return 2*a; } } template Mix2(T) { mixin Mix1!(T); void bar(T a) { return foo(a); } } And another thing comes to my mind: can you mixin all kinds of templates? Including specialized ones? Hauke
May 16 2004
parent "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c87gmb$1f8j$1 digitaldaemon.com...
 First: there is a typo at the top.

 mixin TemplateIdentifier (! TemplateArgumentList ) ;
 mixin TemplateIdentifier (! TemplateArgumentList ) MixinIdentifier ;

 should be (judging from the examples):

 mixin TemplateIdentifier !( TemplateArgumentList ) ;
 mixin TemplateIdentifier !( TemplateArgumentList ) MixinIdentifier ;

 For a moment I thought you'd have to use !( for templates and (! for
 mixins. I had already started to formulate a flame mail in my head ;).
Fixed.
 The second thing is a question. Can mixins mix-in other mixins? I.e.

 template Mix1(T)
 {
 void foo(T a) { return 2*a; }
 }

 template Mix2(T)
 {
 mixin Mix1!(T);

 void bar(T a) { return foo(a); }
 }
Yes!
 And another thing comes to my mind: can you mixin all kinds of
 templates? Including specialized ones?
Yes, just like for regular template instantiations.
May 16 2004
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:

 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory. That
 means there may be some pretty cool uses for it I've never thought of. Let
 me know what you think, and if I missed the boat completely <g>.
 
 www.digitalmars.com/d/mixin.html
 
 
Oh yeah, forgot to mention: THANKS very much for implementing this! I think this is a kick-ass feature! Hauke
May 16 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c87go0$1f8j$2 digitaldaemon.com...
 Walter wrote:

 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory.
That
 means there may be some pretty cool uses for it I've never thought of.
Let
 me know what you think, and if I missed the boat completely <g>.

 www.digitalmars.com/d/mixin.html
Oh yeah, forgot to mention: THANKS very much for implementing this! I think this is a kick-ass feature!
You're welcome! Now, I want to see a kick-ass use for this, so I can write a magazine article about it! A use that is cool, not easilly expressed in other languages, and so would highlight the capabilities of D.
May 16 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:

 
 [...] I want to see a kick-ass use for this, so I can write a
 magazine article about it! A use that is cool, not easilly expressed in
 other languages, and so would highlight the capabilities of D.
 
Singletons come to mind: singleton.d: template Singleton(T) { private static T _instance; private static bool _deleted = false; public static T get() { assert(!_deleted); if (_instance is null) { _instance = new T(); } return _instance; } public static void destroy() { assert(!_deleted); delete _instance; _instance = null; } } // best global symbol name ever template the(T) { T the() { return T.get(); } } main.d: import singleton; final class Foo { mixin Singleton!(Foo); private this() { ... } } int main() { Foo theFoo = the!(Foo)(); } If you want to do the same in C++, you're pretty much stuck using the preprocessor since you also have to deal with copy constructors and the like. The only catch with the D singleton is that it's up to you to make the constructor private. (this could be alleviated by deferring construction to a create() method, but that's stinky) -- andy
May 16 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
Would it make sense to put the private this() inside Singleton(T) ?

"Andy Friesen" <andy ikagames.com> wrote in message
news:c88cc4$2mrb$1 digitaldaemon.com...
 Walter wrote:

 [...] I want to see a kick-ass use for this, so I can write a
 magazine article about it! A use that is cool, not easilly expressed in
 other languages, and so would highlight the capabilities of D.
Singletons come to mind: singleton.d: template Singleton(T) { private static T _instance; private static bool _deleted = false; public static T get() { assert(!_deleted); if (_instance is null) { _instance = new T(); } return _instance; } public static void destroy() { assert(!_deleted); delete _instance; _instance = null; } } // best global symbol name ever template the(T) { T the() { return T.get(); } } main.d: import singleton; final class Foo { mixin Singleton!(Foo); private this() { ... } } int main() { Foo theFoo = the!(Foo)(); } If you want to do the same in C++, you're pretty much stuck using the preprocessor since you also have to deal with copy constructors and the like. The only catch with the D singleton is that it's up to you to make the constructor private. (this could be alleviated by deferring construction to a create() method, but that's stinky) -- andy
May 16 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:
 Would it make sense to put the private this() inside Singleton(T) ?
 
You could, but it's almost completely fire-and-forget as written. Safety vs transparency. :) -- andy
May 16 2004
parent reply Mike Swieton <mike swieton.net> writes:
On Sun, 16 May 2004 12:14:45 -0700, Andy Friesen wrote:
 Walter wrote:
 Would it make sense to put the private this() inside Singleton(T) ?
You could, but it's almost completely fire-and-forget as written. Safety vs transparency. :)
How about putting a class invariant in the mixin that assert(instance is this)? Mike Swieton __ But who prays for Satan? Who, in eighteen centuries, has had the common humanity to pray for the one sinner that needed it the most? - Mark Twain
May 16 2004
parent Andy Friesen <andy ikagames.com> writes:
Mike Swieton wrote:

 On Sun, 16 May 2004 12:14:45 -0700, Andy Friesen wrote:
 
Walter wrote:

Would it make sense to put the private this() inside Singleton(T) ?
You could, but it's almost completely fire-and-forget as written. Safety vs transparency. :)
How about putting a class invariant in the mixin that assert(instance is this)?
You can only have one invariant per class, though. Maybe that restriction needs to be removed, since adding to an invariant is something mixins should be able to do. -- andy
May 16 2004
prev sibling next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
Andy Friesen wrote:
 Singletons come to mind:
I'm planning on using mixins in Sinbad for exactly that purpose. (See the proposal for it at dsource.) And possibly quite a few others, such as the event system, which is something that had been giving me dizzy spells before. These things could prove useful to no end... -C. Sauls -Invironz
May 16 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
Aren't you missing a line, see below. :)
Regan.

On Sun, 16 May 2004 11:40:09 -0700, Andy Friesen <andy ikagames.com> wrote:
 [...] I want to see a kick-ass use for this, so I can write a
 magazine article about it! A use that is cool, not easilly expressed in
 other languages, and so would highlight the capabilities of D.
Singletons come to mind: singleton.d: template Singleton(T) { private static T _instance; private static bool _deleted = false; public static T get() { assert(!_deleted); if (_instance is null) { _instance = new T(); } return _instance; } public static void destroy() { assert(!_deleted); delete _instance; _instance = null;
//Line missing? deleted = true;
          }
      }

      // best global symbol name ever
      template the(T) {
          T the() {
              return T.get();
          }
      }

 main.d:

      import singleton;

      final class Foo {
          mixin Singleton!(Foo);

          private this() { ... }
      }

      int main() {
          Foo theFoo = the!(Foo)();
      }

 If you want to do the same in C++, you're pretty much stuck using the 
 preprocessor since you also have to deal with copy constructors and the 
 like.

 The only catch with the D singleton is that it's up to you to make the 
 constructor private.  (this could be alleviated by deferring 
 construction to a create() method, but that's stinky)

   -- andy
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 16 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Regan Heath wrote:

 Aren't you missing a line, see below. :)
 Regan.
doh. Yes. The approach is sound, though. -- andy
May 16 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Sun, 16 May 2004 17:54:56 -0700, Andy Friesen <andy ikagames.com> wrote:
 Regan Heath wrote:

 Aren't you missing a line, see below. :)
 Regan.
doh. Yes. The approach is sound, though.
Yes, I only mentioned the mistake cos I reckon everyone has copied it and is about to use it! -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 16 2004
prev sibling next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c87go0$1f8j$2 digitaldaemon.com...
 
Walter wrote:


I have this mostly implemented. It's been based on a lot of your
suggestions. The way I did it is, I think, pretty unexplored territory.
That
means there may be some pretty cool uses for it I've never thought of.
Let
me know what you think, and if I missed the boat completely <g>.

www.digitalmars.com/d/mixin.html
Oh yeah, forgot to mention: THANKS very much for implementing this! I think this is a kick-ass feature!
You're welcome! Now, I want to see a kick-ass use for this, so I can write a magazine article about it! A use that is cool, not easilly expressed in other languages, and so would highlight the capabilities of D.
Well, right now I see mixins as a way to upgrade the language to the power of the C++ preprocessor. Mixins are basically what you'd think of as macros in C++, only as a real language construct with all the subtle advantages of readability, type-safety, etc. But I doubt you'd find something that cannot be done with a macro in C++. The main difference seems to be that the class that uses a mixin can overwrite definitions from the mixin. In C++ you'd have to write an intermediate class to do something like that, but it is still feasible. So I think the main point is that you get the power of macros without the headaches. This is quite an accomplishment if you see how other Maybe I'm missing some other, more revolutionary use, though ;). Hauke
May 16 2004
prev sibling next sibling parent reply "fred" <info fleet-manage.com> writes:
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


"Walter" <newshound digitalmars.com> wrote in message =
news:c889f4$2io2$1 digitaldaemon.com...
=20
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c87go0$1f8j$2 digitaldaemon.com...
 Walter wrote:

 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored =
territory.
 That means there may be some pretty cool uses for it I've never =
thought of.
 Let me know what you think, and if I missed the boat completely =
<g>.
 www.digitalmars.com/d/mixin.html
Oh yeah, forgot to mention: THANKS very much for implementing this! =
I
 think this is a kick-ass feature!
=20 You're welcome! Now, I want to see a kick-ass use for this, so I can =
write a
 magazine article about it! A use that is cool, not easilly expressed =
in
 other languages, and so would highlight the capabilities of D.
=20
This is GREAT (8^) I personally like the way you have handled scope of mixins, makes = perfect sense to me. BTW you missed one of the (! in the text and can i suggest a minor = grammatical change (in bold); A TemplateMixin can occur in declaration lists of modules, classes, = structs, unions, and as a statement. The TemplateIdentifier refers to a = TemplateDeclaration. If the TemplateDeclaration has no parameters, the = mixin form that has no (!TemplateArgumentList) can be used.=20 Unlike a template instantiation, a template mixin's body is evaluated = within the scope where the mixin appears, not where the template = declaration is defined. It is analogous to cutting and pasting the body = of the template into the location of the mixin. It is useful for = injecting parameterized 'boilerplate' code, as well as for creating = templated nested functions, which is not possible with template = instantiations.=20 As an advocate of class aggregation, I believe your implementation has a = very promising future in this area. I also think that MIXIN's are D's answer to MI, and plan to pursue this = with some examples. Watch this space fred
May 16 2004
parent "Walter" <newshound digitalmars.com> writes:
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks, I updated with your fixes.
May 16 2004
prev sibling next sibling parent "Pablo Aguilar" <paguilarg hotmail.com> writes:

that comes to mind for mixins is doing data validation... no code at hand,
sorry, but think of doing an IntValidator, DoubleValidator, RangeValidator
mixins (which would work kinda like MFC's DDX_Validate) and so on, and just
mix 'em into your form class appropriately for each control you'd like to
validate...

 Walter wrote:

 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored
territory.
 That
 means there may be some pretty cool uses for it I've never thought of.
Let
 me know what you think, and if I missed the boat completely <g>.

 www.digitalmars.com/d/mixin.html
Oh yeah, forgot to mention: THANKS very much for implementing this! I think this is a kick-ass feature!
You're welcome! Now, I want to see a kick-ass use for this, so I can write
a
 magazine article about it! A use that is cool, not easilly expressed in
 other languages, and so would highlight the capabilities of D.
May 17 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c889f4$2io2$1 digitaldaemon.com...
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c87go0$1f8j$2 digitaldaemon.com...
 Walter wrote:

 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory.
That
 means there may be some pretty cool uses for it I've never thought of.
Let
 me know what you think, and if I missed the boat completely <g>.

 www.digitalmars.com/d/mixin.html
Oh yeah, forgot to mention: THANKS very much for implementing this! I think this is a kick-ass feature!
You're welcome! Now, I want to see a kick-ass use for this, so I can write a magazine article about it! A use that is cool, not easilly expressed in other languages, and so would highlight the capabilities of D.
I've got one of those - and the article half planned - as soon as I have an implementation that works. ;)
May 17 2004
prev sibling next sibling parent imr1984 <imr1984_member pathlink.com> writes:
so i guess this means that structs can have inheritance now (in a way)? Thats
great.

In article <c876sh$10r7$1 digitaldaemon.com>, Walter says...
I have this mostly implemented. It's been based on a lot of your
suggestions. The way I did it is, I think, pretty unexplored territory. That
means there may be some pretty cool uses for it I've never thought of. Let
me know what you think, and if I missed the boat completely <g>.

www.digitalmars.com/d/mixin.html
May 16 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Walter wrote:

 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory.
 That means there may be some pretty cool uses for it I've never thought
 of. Let me know what you think, and if I missed the boat completely <g>.
 
 www.digitalmars.com/d/mixin.html
Cool! Will something like this work: // helper to make an array "literal" with value semantics // Example: // uintn!(3)(100,200,300) struct InlineArray(T,int N) { static .InlineArray!(T,N) opCall(T x0,...) { .InlineArray!(T,N) res; res.array[] = (&x0)[0..N][]; return res; } mixin CommonInlineArray!(T,N); // add generic N-D members } struct InlineArray(T,int N:2) { // avoid using varargs for safety and speed static .InlineArray!(T,N) opCall(T x0, T x1) { .InlineArray!(T,N) res; res.array[0] = x0; res.array[1] = x1; return res; } T x() { return array[0]; } void x(T val) { array[0] = val; } T y() { return array[1]; } void y(T val) { array[1] = val; } mixin CommonInlineArray!(T,N); // add generic N-D members } // InlineArray members that are independent of dimension private template CommonInlineArray(T,int N) { T[N] array; static .InlineArray!(T,N) opCall(T[N] x) { .InlineArray!(T,N) res; res.array[] = x[]; return res; } T opIndex(int i) { return array[i]; } void opIndex(int i, T val) { array[i] = val; } // todo: arithmetic, cmp, etc } template intn(N) { alias InlineArray!(int,N) uintn; } int main() { intn!(2) p = intn!(2)(4,5); printf("x=%d y=%d array=%p\n", p.x, p[1], p.array); }
May 16 2004
prev sibling next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory. That
 means there may be some pretty cool uses for it I've never thought of. Let
 me know what you think, and if I missed the boat completely <g>.
 
 www.digitalmars.com/d/mixin.html
I was really excited to read the proposal. As usual, you take our ideas and expand and generalize them. However, I'm pretty concerned about the various rules to resolve conflict. I'm particularly scared about the rule that "Mixin has its own scope." These sound very hard to understand, and very hard to read! Can you explain why you defined these rules?
May 16 2004
parent "Walter" <newshound digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c88d0c$2nnf$1 digitaldaemon.com...
 Walter wrote:
 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory.
That
 means there may be some pretty cool uses for it I've never thought of.
Let
 me know what you think, and if I missed the boat completely <g>.

 www.digitalmars.com/d/mixin.html
I was really excited to read the proposal. As usual, you take our ideas and expand and generalize them. However, I'm pretty concerned about the various rules to resolve conflict. I'm particularly scared about the rule that "Mixin has its own scope." These sound very hard to understand, and very hard to read! Can you explain why you defined these rules?
I went around in circles on this for a while - the mixins needed to be overridable in a simple manner. Finally, I decided to use rules analogous to how names come in from an 'import'. In fact, it uses the same code <g>.
May 16 2004
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <newshound digitalmars.com> wrote in
news:c876sh$10r7$1 digitaldaemon.com: 

 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored
 territory. That means there may be some pretty cool uses for it I've
 never thought of. Let me know what you think, and if I missed the boat
 completely <g>. 
 
 www.digitalmars.com/d/mixin.html
This is pretty cool! A few question: Can you mixin that same mixin twice ( or more ) if you use a Mixin Identifier? template foo(alias b) { int abc() { return b; } } void test() { int x = 8; int y = 9; mixin Foo!(x) XFoo; mixin Foo!(y) YFoo; assert(XFoo.abc() == 8); assert(YFoo.abc() == 9); }
May 16 2004
parent "Walter" <newshound digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns94EB98EDD61ACpatcodemooncom 63.105.9.61...
 This is pretty cool!

 A few question:

 Can you mixin that same mixin twice ( or more ) if
 you use a Mixin Identifier?
Yes.
 template foo(alias b)
 {
   int abc() { return b; }
 }

 void test()
 {
   int x = 8;
   int y = 9;

   mixin Foo!(x) XFoo;
   mixin Foo!(y) YFoo;

   assert(XFoo.abc() == 8);
   assert(YFoo.abc() == 9);
 }
May 16 2004
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <newshound digitalmars.com> escribió en el mensaje
news:c876sh$10r7$1 digitaldaemon.com
| I have this mostly implemented. It's been based on a lot of your
| suggestions. The way I did it is, I think, pretty unexplored territory.
That
| means there may be some pretty cool uses for it I've never thought of. Let
| me know what you think, and if I missed the boat completely <g>.
|
| www.digitalmars.com/d/mixin.html

I still fail to see the big picture, but since others have said it's a good
thing, then I guess they're right.
One question: so a mixin, in some way, would be like an import?

-----------------------
Carlos Santander Bernal
May 16 2004
parent "Walter" <newshound digitalmars.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:c88o3c$5pf$1 digitaldaemon.com...
 I still fail to see the big picture, but since others have said it's a
good
 thing, then I guess they're right.
 One question: so a mixin, in some way, would be like an import?
The scoping and overriding rules are the same as for imports.
May 16 2004
prev sibling next sibling parent reply "Tony" <talktotony email.com> writes:
The mixin example overrides the definition of "x" within the function
"test()".

Doesn't this violate the D rule that a symbol can't be multiply defined
within a function?

Tony

"Walter" <newshound digitalmars.com> wrote in message
news:c876sh$10r7$1 digitaldaemon.com...
 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory.
That
 means there may be some pretty cool uses for it I've never thought of. Let
 me know what you think, and if I missed the boat completely <g>.

 www.digitalmars.com/d/mixin.html
May 16 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Tony" <talktotony email.com> wrote in message
news:c89gd4$19nf$1 digitaldaemon.com...
 The mixin example overrides the definition of "x" within the function
 "test()".

 Doesn't this violate the D rule that a symbol can't be multiply defined
 within a function?
That rule is probably going to have to go away :-(
May 17 2004
parent reply Sean Kelly <sean ffwd.cx> writes:
Walter wrote:
 "Tony" <talktotony email.com> wrote in message
 news:c89gd4$19nf$1 digitaldaemon.com...
 
The mixin example overrides the definition of "x" within the function
"test()".

Doesn't this violate the D rule that a symbol can't be multiply defined
within a function?
That rule is probably going to have to go away :-(
Looks very promising, but it could also cause quite a bit of unexpected behavior as the implementation details of a mixin can affect the calling function. I don't suppose there are scope resolution operators to allow the caller to specify which instance of x he wants to access? Sean
May 17 2004
parent Sean Kelly <sean ffwd.cx> writes:
Sean Kelly wrote:
 Looks very promising, but it could also cause quite a bit of unexpected 
 behavior as the implementation details of a mixin can affect the calling 
 function.
I take it back. The variable overriding feature pretty much takes care of this. Sean
May 17 2004
prev sibling next sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Great work! Apart from my comments about the general problem that the
untyped compile-time language of D will probably prove to be extremely hard
to debug, I really like this absolutely powerful concept of mixins.

Anybody who knows Sather will realize, that mixins contain the complete
concept of implementation inheritance!

To those unfamiliar with Sather: in that highly interesting language,
inheritance is completely split up into interface inheritance and
implementation inheritance. Interface inheritance is just what we have in D
already. Implementation inheritance is just that kind of parameterized
cut-and-paste operation that mixins allow. Taking both together, it becomes
obvious, that direkt inheritance is not necessary at all any more!

All the problems of multiple-inheritance in C++ come from binding together
the inheritance of the class interface and the implementation of its
routines. As you can easily see in D: neither interfaces nor mixins have
problems with multiple inheritance (resp. inclusion of several mixins into
one class definition)

Conclusion: multiple interface inheritance and mixins taken together are a
complete replacement for the multiple inheritace that was dropped!
May 17 2004
prev sibling parent reply "Greg Vanore" <dazden at.dazden.dot.org> writes:
This is a great feature for D.

Coming from an enterprise software background, I can tell you that it may
have a lot of use for cross-cutting concerns.  OOP generally puts tight
coupling between a system-level concern and the business logic of an
application, but with mixins, you could theoretically define a solution to a
problem and apply it generically across business classes.  I'll play more
and hopefully post something demonstrating some aspect-oriented programming
techniques with D and mixins.

"Walter" <newshound digitalmars.com> wrote in message
news:c876sh$10r7$1 digitaldaemon.com...
 I have this mostly implemented. It's been based on a lot of your
 suggestions. The way I did it is, I think, pretty unexplored territory.
That
 means there may be some pretty cool uses for it I've never thought of. Let
 me know what you think, and if I missed the boat completely <g>.

 www.digitalmars.com/d/mixin.html
May 17 2004
parent Sean Kelly <sean ffwd.cx> writes:
Greg Vanore wrote:
 
 Coming from an enterprise software background, I can tell you that it may
 have a lot of use for cross-cutting concerns.  OOP generally puts tight
 coupling between a system-level concern and the business logic of an
 application, but with mixins, you could theoretically define a solution to a
 problem and apply it generically across business classes.  I'll play more
 and hopefully post something demonstrating some aspect-oriented programming
 techniques with D and mixins.
Excellent point. This may make implementing Aspect Oriented Programming in D fairly easy, which is a technique that IMO has tremendous potential. Sean
May 17 2004