sweep : Haxe 3 support

[zjnue]

No description provided.

[cliffhall]

This pull request says Haxe 3 support, but it doesn't mention the changes of the switch statements to if statements in several classes. Why was this done? Does switch not work in Haxe 3? Otherwise, those changes should not have been made. This is a port of the AS3 utility. It should mirror that code as closely as the language you are porting to allows. Otherwise when changes are made to the reference, the changes to the ports are the most straightforward.

I understand some people prefer if/else if/else to switch/case but this really isn't the place to impose that preference.

If this sweep is about upgrading to Haxe 3, then lets keep it to code that has to be changed for that reason.

[zjnue]

Hi!

Of course - I agree with you 100%.

The change was certainly made for a reason, but admittedly, perhaps a little premature.
Right now, Haxe 3.0 is in a RC1 phase. For RC1 a change in switch syntax is indeed required:
http://haxe.org/manual/haxe3/migration#switch-changes
http://haxe.org/manual/pattern_matching

So while pattern matching is more expressive and powerful on the whole, it does require a change for normal "captured variables" as per this thread:
https://groups.google.com/forum/?hl=en#!topic/haxelang/VE_eji0WmBc

So, right now, if we keep with the switch statement,

switch ( message.getType() )
{
case Message.NORMAL:
case FilterControlMessage.SET_PARAMS:

would need to change to:

switch ( message.getType() )
{
case x if(x == Message.NORMAL):
case x if(x == FilterControlMessage.SET_PARAMS):

etc .. and as a result require more elaborate conditional compilation statements to support both Haxe 2 and Haxe 3 in the same file ... so changing to an IF construct seemed easiest.

Right now, for RC1, it is possible to keep the old syntax (as per top link) by specifying:
-D no-pattern-matching

..but one might desire the pattern matching power in other parts of one's project..

As the email thread suggests however, it may be that another per-switch metadata specification will be supported for Haxe 3.0 FINAL in order to keep the old behaviour, so again ... I may have created too much confusion by these somewhat early updates - just wanted to contribute back while at it.

Taking it further, having both Haxe 2 and Haxe 3 support in the same files may give the incorrect impression that Haxe syntax is messy, so indeed, having separate CLEAN branches allow for more readable language and to utilize the best constructs for each version ... again, I merely tried to push through quick updates.

Given all the above, please feel free to settle on the approach you deem best.

Cheers!

[cliffhall]

Ok, I see your dilemma. So, I'll merge this now.

"separate CLEAN branches allow for more readable language and to utilize the best constructs for each version"

This would certainly be nice. Perhaps revisit the problem after the official H3 syntax is sussed.

[zjnue]

Sure, thanks.