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”:

http://haxe.org/ref/type_params

Here is a slideshow, GIT Code Sample, and screencast video about the fantastic AS3-Signals.

http://www.rivellomultimediaconsulting.com/as3-signals-introduction/

I took a quick look at the circleplayer tutorial: Perhaps you are having difficulty with the HTML part of it? WordPress’s editor tends to mangle markup for stuff like that. I’m sorry I couldn’t be more helpful; I’m just not sure what problem you are having. If you have the excellent Firefox plugin Firebug, check to make sure all your scripts are included properly on the theme side, then check that the html markup didn’t get mangled by WordPress.

Fatal error: Cannot unset string offsets in /wp-content/plugins/scripts-n-styles/includes/class.SnS_Admin_Meta_Box.php on line 375

the change gets saved, but I have to reload the page in order to see it.

Was there something else I need to check off on the plugin to get this to work?

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.

On the tech side, the reality is, Flash has always been in hostile territory when it comes to web browsers, they just had a multi-year opportunity to grab market share while IE sat on it’s hands. But browser makers essentially all want out from the problems that come with plugin architectures in general, including Google lately – and they are using the migration to mobile web as an opportunity. Basically, its not personal (except in Firefox’s case), but the landscape is hostile toward plugins, and Flash is the plugin vanguard.

The big picture though, is that Apps and middleware are the new future for the lucrative, expanding (compared with the desktop) mobile market – Adobe just didn’t commit to that fast enough. The decisions they made last week show they are now committed. They had such a comfortable position in the “browser era” (see previous post) can you really blame them for almost missing it?

It wasn’t exactly the clearest crystal ball reading (predicting the future never is), but they banked on the browser continuing to be THE web platforms going forward, as it had been for the last half decade. The big problem is, it will be! On the desktop. On the mobile web it will be apps.

Why did this PR problem erupt? Adobe simply didn’t explain any of that split or the new reality in a cohesive digestible narrative, and instead made moves which allowed their competitor’s anti-brand attributes to stick. That was their only mistake, and it was mammoth.

I’m hoping they can still make the sell though (still waiting). I really want to be able to continue to use their AIR platform for mobile apps – there’s really nothing else out there quite like it. But they are going to have to make a move pretty soon.

I’ve tried it both ways – it’s more consistent if dispatches immediately Just make sure you store your current value locally, and check it in your listener. There are browser quirks that’ll cause this to fire at any rate, so it’s important to check the incoming value against your current state. You should probably also be filtering the URL data, to make sure it’s the same when it does come back from the browser (each of which encode special characters differently – ugh). At this point, I’ve actually been recommending alternative frameworks to history keeper, I just haven’t been on top of maintaining it, and there are some vital tools missing from the stack (like a URL filtering/cleaning tool, and some kind of state manager). Have a look at jQuery BBQ as a good alternative.

thanks so much

But what Adobe has just conceded puts the nail in the coffin that the “Flash Platform” could be considered as an alternative to the “Web Platform”. What Adobe whiffed on was not realizing this years earlier and shifting focus of Flash (and PDF) to be complementary extensions to, rather than competitors for the Open Web. Now it’s too late. The Open Web has moved on, and past. And since Adobe is (belatedly) shifting investments to solutions for the Web, chances are that Flash’s niche for video and animations will narrow sooner rather than later. And since Adobe never succeeded in getting substantial enterprise developer market share with Flex/AIR, and even Microsoft is now going to HTML/JS for desktop apps and RIAs in Win 8, that part of Adobe’s work could well fold up its tent a lot sooner. I.e. it’s a loss-maker for Adobe, and Adobe’s tools will increasingly (necessarily) be about making HTML5 RIAs. I mean, from a branding POV (and to continue to save face lest the somnolent Adobe Board wake up to the magnitude of mismanagement) they may rebrand PhoneGap as “AIR 4.0″, they may even put some Flash integration in there, but it won’t be AIR per se.

Adobe really needs to make a play to increase awareness of this valuable platform.

My optimism on the platform hasn’t changed – I still think AIR represents a ton of opportunity.