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

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?

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

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 related languages fail to provide that power (see Java or C#).

Maybe I'm missing some other, more revolutionary use, though ;).

Hauke

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

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

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

"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);
}

"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

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