I think the point that Aino Vonge Corry was trying to reach before the discussion descended into the age old childish argument of which language is best, was that the patterns do exist where ever they can be applied but that some languages express them more elegantly, to the point at which they seem to vanish I think she cited Visitor as one of those patterns that are expressed so easily in FP that it need not be explicitly mentioned, it’s there, it’s just totally hidden.*

A programming language is simply a way to describe the solution to a problem, the fact that one language describes a solution to a particular problem better than another one is neither here nor there. The solution still exists and a concise way to talk about the solution is to use the language of patterns as they are programming language agnostic.

I am struggling to get my point across, this is due to my lack language but essentially the solution to a problem should be given as the “what” needs doing not the “how” it will be done, this is the job of the programming language itself.

I am sure I haven’t been able to explain what I mean and for that will probably be flamed to death, but for all those that do disagree don’t simply say “your wrong”, there is nothing I can do with this advice, tell me why I am wrong.

*By “hidden” I do mean VERY hidden, but at the end of the day remember that whatever language we express solutions with at the end of the day they all become state transfers and tuples in a Turing machine.

Anyway, the success of the open source Flex Framework demonstrates what I meant. That project does receive the kind of positive attention from the community that good usable open source projects tend to attract.

Even Tamarin (which was largely seen as a failed OSS experiment within Adobe, if I read those tea leaves correctly) has received some positive results on the smaller parts of it (nano-jit) that were adopted by Mozilla (that project was largely an unusable code dump – if it had been released within a buildable framework, I bet it would have been more successful).

Anyway, I can imagine some risks with opening the source (particularly with Apple and forking) – but I really think that can be mitigated with a proper management/rollout/transition plan.

Apologies for my slowness in replying to you.

Firstly, your code example looks about right to me. Looks like we both can conceed to each other, as I conceed that whilst it is possible to put Flex events in interfaces, it is unlikely anyone would.

Perhaps I have the Flex event model wrong, but I was under the impression that many events are dispatched UIComponent.callLater() and thus fire off the frame timer. This would make them asynchronous.

As for the rest, I have no argument over the superiority of signals versus Flex events.

I agree that putting events/signals in AS3 interfaces isn’t as good as we would imagine in a more expressive language. But that doesn’t take away from the value added by the interface as it stands.

For me and others, it’s a significant improvement over using string-based channels. The contract is strengthened by making the events/signals tangible properties of the object. I would argue that the delta of improvement by doing this is greater than the remaining amount that isn’t yet possible. Events/signals as properties eliminate the possibility of many wiring mistakes that would not even generate a run-time error. But I need to do a blog post on that. =)

Thanks again for initiating this discussion; I think it’s fruitful.

I assume you’re saying there’s no way for the *compiler* to know the signal parameters. I agree, and it really bugs me. This is a language limitation of AS3, as far as I can see.

I would say this is incorrect, unless you have a different definition of “asynchronous”.

A method executing synchronously remains in the same call stack and blocks progress of the program until it is finished. Asynchronous execution is non-blocking. Obligatory Wikipedia link:

http://en.wikipedia.org/wiki/Asynchronous_I/O

Signal and EventDispatcher are blocking and synchronous. If Signal used Timer on dispatch(), it would be asynchronous.