massive-oss/msignal

A Haxe port of the ActionScript 3 Signals library that leverages Haxe type parameters. Supports AVM1, AVM2, JavaScript, Neko and C++.

msignal's Issues

Listeners added while dispatching are dispatched.

My use case:

I have a Pointer class with a Signal, down. When the pointer is clicked down, the down signal dispatches. In this case I am creating a new Scene in the game that is registering new slots with the down signal. These new slots are fired immediately. That is no good for me because the Scene is brand new and the player clicked the mouse before the scene was created. Ideally, the signals would not dispatch to the new slots/listeners.

In writing this, I have figured out a workaround that will work in this case, but I would prefer signals to simply not dispatch immediately as this is unlikely to be the only instance that this occurs.

My thoughts on how to solve this are:

1. Add a _dispatching variable and set it to true while dispatching...
2. When listeners are added while dispatching, store them in a temporary list
3. When finished dispatching, then add them to the slot list

EventSignals don't work in my case either as I am piggybacking off of two separate event systems (pixijs and openfl) which already handle everything I need. I am simply unifying the interfaces.

Pattern of use

I'm wrapping my head around msignal and mmvc - and my background is native iOS development, which skews my perspective.

In all the examples of signals that I see the both your implementation and Robot Legs, it appears that either instance variable is being passed back, and frequently very basic 'something changed' evens occur.

Is there a more appropriate pattern that would include the object being changed, and the before and after values? (similar to Key-Value-Observing, if that concept is familiar?) I can see how I could build that from msignal, but I wanted to make sure there was something I was missing regarding the intent of the framework., or if there was a language feature of Haxe that has eluded me.

Signal registerListener

function registerListener(listener:TListener, once:Bool=false, priority:Int=0):TSlot
    {
        if (registrationPossible(listener, once))
        {
            var newSlot = createSlot(listener, once, priority);

            if (!priorityBased && priority != 0) priorityBased = true;
            if (!priorityBased && priority == 0) slots = slots.prepend(newSlot);
            else slots = slots.insertWithPriority(newSlot);

            return newSlot;
        }

        return slots.find(listener);
    }

Why newSlot prepend?
Right use append.

Can't serialise Slot => infinite loop

Hi,
A Signal, and therefore a Solt, is serialisable only when no listener has been added.
If you add a listener you get two issues, at least on flash9 target:

• the serialiser gets into an infinite loop because of the 'signal' field of Slot. It tries to serialise signal, so it tries to seralise its slots list, so it serialise the first slot, so it serialise the field signal of the slot, which points to the signal itself, so it tries to serialise again the self signal etc.
  Solution: would be to implement custom hxSerialise and hxUnserialise functions for a Slot class to handle signal field differently.
• on flash9 target: listener field is taken by haxe.Serialiser has a variable and tries to serialise it, but then throw an exception because it can't serialize a function. It's because the field is a $field variable behind getter setter. Getting rid if @isvar don't fix it.
  When i use a serialiser that override serializeClassFields to avoid the serialisation of fields that are Functions, it fixes the issue. i add this line in the loop:
  if (Type.typeof(Reflect.field(v, f)) == TFunction) continue;
  just before
  serializeString(f);
  serialize(Reflect.field(v,f));

I think its more a problem for haxe compiler and Serialiser then mSignal, but you need to fix it to get the first issue of infinit loop that is more a mSignal issue.

Thanks

Make use of inlining

Hi,

Thanks for that simple and efficient library. Would you mind inlining all the appropriate functions ?

I would do it myself and send a pull request, but I'm afraid I may be a little heavy handed with inlining. Might as well be done by someone who fully knows how it's best used :)

Thanks either way !

Is this project stable?

Is this dead/stable?
Cheers.

Issues with haxe 4 preview 5

Hi,
got errors with haxe 4 preview 5.
msignal/1,2,4/msignal/SlotList.hx:80: characters 2-42 : length: Custom property accessor is no longer supported, please use get

msignal/1,2,4/msignal/Slot.hx:50: characters 2-55 : listener: Custom property accessor is no longer supported, please use set

ValueClasses never used

https://github.com/massiveinteractive/msignal/blob/master/src/msignal/Signal.hx#L48

valueClasses must be removed in favor of generics

Cannot compile using Haxe 3 RC

I'm getting the following error message if I use Haxe 3 RC (Win):

"\haxe\3.00/lib\msignal/1,1,2/msignal/Slot.hx:32: lines 32-96 : Recursive constraint parameter is not allowed"

SlotList throws Error in php

The php target version will throw exception: "Parameters head and tail are null. Use the NIL element instead."

it is because the generated code hase two times the following line at the end of file SlotList.class.php:
msignal_SlotList::$NIL = new msignal_SlotList(null, null);

I think it comes from the fact that in haxe code you have two ways of initialisation of NIL property:
one is: static function init() { NIL = new SlotList<Dynamic, Dynamic>(null, null); }
the other is: public static var NIL:SlotList<Dynamic, Dynamic> = new SlotList<Dynamic, Dynamic>(null, null);

I tried to delete the first one, and it seems to work fine either in php and other targets.
Why did you need this hackish init? was it for haxe2 init?

Could you please delete this line or properly switch init cases with #if haxe3 please?
Thanks

Slot params must be typed

https://github.com/massiveinteractive/msignal/blob/master/src/msignal/Slot.hx#L165

param1:TValue1
param2:TValue2

Can't compile to Java (Haxe 3)

I get an error regarding the Slot1 constructor:

Super call must be the first call when extending native types.

The super call is the first and only call in the constructor, so I'm assuming it's code added in by some pre-processor (or perhaps it's just an issue in the Java target).

Can we have Signal3 and Signal4?

[IS-19] Unable to compile Signal and EventSignal with Mockatoo on Haxe 3.2.0 and newer

I tried to compile unit tests that used mockatoo. I got those errors:

HaxeWrapper.hx:73: Signal.hx:202: lines 202-205 : Field createSlot overloads parent class with different or incomplete type
HaxeWrapper.hx:73: Signal.hx:202: lines 202-205 : listener : (Void -> Void) -> ?once : Null<Bool> -> ?priority : Null<Int> -> msignal.Slot0 should be listener : (Void -> Void) -> ?once : Bool -> ?priority : Int -> msignal.Slot0
HaxeWrapper.hx:73: Signal.hx:202: lines 202-205 : Null<Bool> should be Bool
HaxeWrapper.hx:73: Signal.hx:132: lines 132-146 : Field registerListener overloads parent class with different or incomplete type
HaxeWrapper.hx:73: Signal.hx:181: lines 181-206 : Defined in this class
HaxeWrapper.hx:73: Signal.hx:132: lines 132-146 : listener : (Void -> Void) -> ?once : Null<Bool> -> ?priority : Null<Int> -> msignal.Slot0 should be listener : (Void -> Void) -> ?once : Bool -> ?priority : Int -> msignal.Slot0
HaxeWrapper.hx:73: Signal.hx:132: lines 132-146 : Null<Bool> should be Bool
HaxeWrapper.hx:73: Signal.hx:181: lines 181-206 : Defined in this class
Error: Error compiling hxml for js

I think it has something to do with the different behaviour of Haxe 3.2+ when dealing with parameters with default value and optional parameters (see discussion of issue HaxeFoundation/haxe#4793).

It might be the problem of mockatoo on Haxe 3.2+.

What helps is a change of problematic method(s) from

override function createSlot(listener:Void -> Void, once:Bool=false, priority:Int=0)

to (once and priority parameters are marked with ?)

override function createSlot(listener:Void -> Void, ?once:Bool=false, ?priority:Int=0)

When this change is introduced, it works with mockatoo well.