define('DISALLOW_FILE_EDIT', true);
I did add something like a GenericSignal test in the repo since this post that performs pretty well on AVM2 based runtimes (but not on iOS) which takes advantage of that “as” performance enhancement: https://github.com/CaptainN/SignalsLite/blob/master/performance-test/CallbacksTest.as
As far as HaXe goes – I just haven’t had the time to really dig in. Some of the questions I would have revolve around what the various features actually compile down to – for example I know (think) that some features like typedef (which other features are based on) are strictly compile time features, and don’t necessarily lead to runtime performance boost – though like I said, I haven’t had the time to dive in and learn the ins and outs. Type params though seem awesome – like generics in C#. I can think of many uses for such a feature.
]]>This example is based on the performance test from Jackson Dunstan’s CallbackTest which I borrowed (I hope that’s ok!):
That’s more than OK! 🙂
I’m interested to see where the strong typing takes you. The biggest downside (IMO) to TurboSignals is what others are mentioning: the need to name a public function onSignal0.
Perhaps, as John Suggests above, a port to HaXe would help out somewhat. For example, using a “Function” type is replaced rather cleanly with a “SignalArg0,SignalArg1->Void” type (change, add, or remove types as needed) and they also support generics/templates through “type params”:
]]>Here is a slideshow, GIT Code Sample, and screencast video about the fantastic AS3-Signals.
http://www.rivellomultimediaconsulting.com/as3-signals-introduction/
]]>Yes exactly. I actually used Jackson’s research (in his “Callback Strategies” – the previous post to his TurboSignals post) to implement SignalsLite, and modified his Callback test – specifically the Runnable example – to test out some ideas.
The difference between TurboSignals and a signals by contract paradigm that I’m working on, is TurboSignals requires you to implement a method called onSignal0, and the arguments passed to dispatch are not typed, where I’m looking to define a formal contract between the class that sends signals, and the consumer. This will allow more appropriate signal names, and compile time argument type checking. Of course, just using onSignal0 is easier (as is using SignalLite), but it’d be nicer to define the signal handlers descriptively (onMouseClicked, etc.).
I will cop to having missed the TurboSignals post until I was pretty far down this rabbit hole though (otherwise I might have just started from that code base). My original intent was to just make a very small Signals implementation (SignalLite and SlotLite), but I couldn’t resist chasing down even greater performance wins. 🙂
]]>I really wish I had any idea at all who posted that. Thanks for the kind words Mr. Travolta! 🙂
]]>