Jarrett Billingsley wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:eidh0g$10e1$1@digitaldaemon.com...
> 
>>> public import std.stdio;
>>> public import std.c.stdlib;
>>> public import std.outofmemory;
> 
> That then works when the class has one signal, but trying to put more than one:
> 
> class Input
> {
>     mixin Signal!(int, int) click;
>     mixin Signal!(char) keyDown;
> }
> 

Good catch - this also happens w/o the 'public import' mod. in std/signals (if you import those into your module) as well.

This is probably a show-stopper, because I don't think this would compete with the current QT signal/slot mechanism, for example, if we have to wrap each Signal with a separate class.

Walter - is there a work-around for this problem, or a 'fix' of some sort planned?

I mean this is very, very cool... QT only recently bowed to market demand for a port to Java (their website used to complain of Java performance issues), and the MOC hack has always been a problem for C++ (IMHO). D is a natural for QT if this can be fixed. I think if it can be fixed, you should approach them with it. It would be huge for D (and potentially for QT as well).

Thanks for these awesome new features!

> Gives..
> 
> C:\dmd\bin\..\src\phobos\std\signals.d(181): Error: dtest.Input.Signal!(int,int).unhook at dtest.d(206) conflicts with dtest.Input.Signal!(char).unhook at dtest.d(206)
> C:\dmd\bin\..\src\phobos\std\signals.d(196): Error: dtest.Input.Signal!(int,int).unhook at dtest.d(206) conflicts with dtest.Input.Signal!(char).unhook at dtest.d(206)
> C:\dmd\bin\..\src\phobos\std\signals.d(232): Error: dtest.Input.Signal!(int,int).unhook at dtest.d(206) conflicts with dtest.Input.Signal!(char).unhook at dtest.d(206)
> C:\dmd\bin\..\src\phobos\std\signals.d(181): Error: dtest.Input.Signal!(int,int).unhook at dtest.d(206) conflicts with dtest.Input.Signal!(char).unhook at dtest.d(206)
> C:\dmd\bin\..\src\phobos\std\signals.d(196): Error: dtest.Input.Signal!(int,int).unhook at dtest.d(206) conflicts with dtest.Input.Signal!(char).unhook at dtest.d(206)
> C:\dmd\bin\..\src\phobos\std\signals.d(232): Error: dtest.Input.Signal!(int,int).unhook at dtest.d(206) conflicts with dtest.Input.Signal!(char).unhook at dtest.d(206)
>> Execution finished.
> 
> :S
> 
> Mixins, mixins, mixins. 
> 
> 

Dave wrote:
> Walter - is there a work-around for this problem, or a 'fix' of some sort planned?

It's already fixed.

Walter Bright wrote:
> Dave wrote:
>> Walter - is there a work-around for this problem, or a 'fix' of some sort planned?
> 
> It's already fixed.

Even more cool!

Walter Bright wrote:
> Dave wrote:
> 
>> Walter - is there a work-around for this problem, or a 'fix' of some sort planned?
> 
> 
> It's already fixed.

Is this a fix we can make ourselves ourselves by tinkering with std/signals.d?  I was going to start playing with std.signals, to see how it stacked up against my current code using Lutger's signal library.  But it's a non-starter without being able to have multiple signals in one class.

--bb

Bill Baxter wrote:
> Is this a fix we can make ourselves ourselves by tinkering with std/signals.d?

http://www.digitalmars.com/d/phobos/signal.d

Walter Bright wrote:
> Bill Baxter wrote:
> 
>> Is this a fix we can make ourselves ourselves by tinkering with std/signals.d?
> 
> 
> http://www.digitalmars.com/d/phobos/signal.d

Ok.  Got it.  Thanks.

But it's
http://www.digitalmars.com/d/phobos/signals.d  << note the 's'


--bb

Walter Bright wrote:
> Bill Baxter wrote:
>> Is this a fix we can make ourselves ourselves by tinkering with std/signals.d?
> 
> http://www.digitalmars.com/d/phobos/signal.d


Here's a few more problems with std.signals:

*) Can't make a global signal.  With Lutger's versions using objects for signals this wasn't a problem.  But a mixin in the global scope causes a "can't have a dtor outside a class" error.

If you stick with mixins for implementing signals, I think there should probabaly be a simple SignalObj class that wraps a signal. Unfortunately   pretty much anything I've tried along these lines starting with

     class SignalObj(T...)
     {
     }

currently generates an ICE.


*) More mixin import scoping issues.
   This seems to be impossible:

   import ssig=std.signals;

   And that isn't fixed by making the std/signals.d imports public.

--bb

Bill Baxter wrote:
> *) Can't make a global signal.  With Lutger's versions using objects for signals this wasn't a problem.  But a mixin in the global scope causes a "can't have a dtor outside a class" error.

Why not just put it in a global class instance?

> If you stick with mixins for implementing signals, I think there should probabaly be a simple SignalObj class that wraps a signal. Unfortunately   pretty much anything I've tried along these lines starting with
> 
>      class SignalObj(T...)
>      {
>      }
> 
> currently generates an ICE.

Please post all examples that generate an ICE to bugzilla.

Walter Bright wrote:
> Bill Baxter wrote:
> 
>> *) Can't make a global signal.  With Lutger's versions using objects for signals this wasn't a problem.  But a mixin in the global scope causes a "can't have a dtor outside a class" error.
> 
> 
> Why not just put it in a global class instance?
> 
>> If you stick with mixins for implementing signals, I think there should probabaly be a simple SignalObj class that wraps a signal. Unfortunately   pretty much anything I've tried along these lines starting with
>>
>>      class SignalObj(T...)
>>      {
>>      }
>>
>> currently generates an ICE.
> 
> 
> Please post all examples that generate an ICE to bugzilla.

I think the one I was hitting was the same as this one I posted with a slightly different description:
   http://d.puremagic.com/issues/show_bug.cgi?id=495

But I went ahead and added the class SignalObj(T...) variant of it. Both make
  Assertion failure: 'global.errors' on line 2752 in file 'template.c'

--bb

Thank-you.