Signals fixes #567
Signals fixes #567
Conversation
…erived class to have any signals All `Signal` methods should be `final` because if they aren't it's impossible to add any signals into a derived class. And yes, lets make `Signal` a `mixin template`.
|
I had been going to use signals, too, but I judged it is unusable, and I implemented it by myself. ( https://github.com/shoo/voile/blob/eac13cac65981101ab7552d8e44cd4b479836f0e/voile/misc.d#L798 ) |
Totally agree. From std.signals docs:
And this limitation in a BUGS section. We need a way to distinguish different types of delegates. @WalterBright wants them to be indistinguishable, but I believe it's a wrong way. I really need ways to:
|
| assert(!o3.i && o3.l == 33 && o3.str == "str3"); | ||
|
|
||
| // delete observers | ||
| delete o1; |
There was a problem hiding this comment.
Can you use destroy (from the object module) instead? delete will be deprecated eventually, so let's not add more of it.
There was a problem hiding this comment.
Added 7134b60.
Not sure if UFCS is better: a.destroy() or destroy(a)?
There was a problem hiding this comment.
I don't think it really matters. Looks good now, thanks!
|
Looks good other than the use of I say we merge this. Better to reject things as early as possible than allow runtime failures to happen. We can always open up the API later if we find a way to solve the aforementioned problems. |
Looks like nobody uses signals...
Maybe, because for now it's unusable because if a class have a signal it's impossible for a derived class to have signals (Issue 8031).
With this pull it's impossible for a derived class to have signals only if a base class has the one and only signal (because of Issue 5028) and this isn't a major luck of functionality.