Constant expression expected

[Jozef Chúťka]

Hi,

I am trying haxe3, and having difficulties with switch statement. I have a js application with following code:

public function keyDown(event:KeyboardEvent)

{

var keyCode = event.keyCode;

switch(keyCode)

{

case tvKey.KEY_RETURN:

tvKey is extern lib:

extern class TVKeyValue

{

public function new():Void;

public var KEY_RETURN(default,null):Int;

}

now compilation throws Constant expression expected. What is your suggestion, is switch not intended to be used in following scenario?

[Juraj Kirchheim]

Because of the new pattern matching, all identifiers are considered
captured variables, so you can in fact no longer do that.

You can use if-statements or a Map mapping key codes to handlers.
Unless I am mistaken, the use of static inline constants might also
work within switch statements.

Regards,
Juraj

[Heinz Hölzer]

you can also do the following:

public function keyDown(event:KeyboardEvent)

{

var keyCode = event.keyCode;

switch(keyCode)

{

case x if(x == tvKey.KEY_RETURN):

case x if(x == tvKey.KEY_SPACE):

best,

h

[Jozef Chúťka]

could you please target me to documentation regarding this pattern?

case x if(x == tvKey.KEY_RETURN):

[Simon Richardson]

Here you go.

http://haxe.org/manual/pattern_matching#guards

Cheers 

si

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jozef Chúťka]

thank you

[clemos]

Hi all,

Sorry to unbury this thread, 

but I just ran into this issue as well, and I find it really odd, to say the least...

Switch/case is a really basic construct, and not being able to use it in its most basic form (variables...) is _very_ weird.

The compiler error message doesn't help much either ("This pattern is unused").

I'm not exactly a newbie in Haxe, but I can easily imagine newcomers' confusion when confronted to such craziness...

The workarounds suggested in this thread and in the manual seem very hacky, also. 

You can either :

- use "if ... else if ... else" 

- or use "case _ if( switchExpr == caseExpr )"

The first suggestion is just plain bad practice in most cases, and the second is even worse, being essentially the same, but in an even more complex and unreadable flavor.

You can also just kill pattern matching globally, which is likely to give you even more problems in case third-party code makes use of it...

I have the feeling it's now much easier to use switch / case for complex stuff (pattern matching), but ITOH so difficult to use it for simple stuff...

Is there any plan to make switch / case constructs more intuitive for common use cases ?

Regards,

Clément

[Simon Richardson]

imho : I think the new stuff should have been called `match` and then we should have left switch alone. 

[TopHattedCoder]

The compiler already has a match expression, which is just a switch on an enum, so that could spark incompatibility with some bits of the compiler.

[Simon Richardson]

I was more thinking about having two types - could be confusing I agree, but not as confusing as wondering why you get a message saying "This pattern is unused".

switch(a) {

case 1: 

case 2:

default: 

}

match(myTree) {

case Leaf(s): s;

case Node(Leaf(s), _): s;
case _: "none";
}

Also it's fundamentally easier to understand what is doing what when glancing at it, especially for beginners to the language. 

I personally think it's to late to change now, but I think it would have been useful.

si

[co...@seasonsoftware.com]

+1 for match()

Couldn't agree more about being easier for beginners. Redefining longtime standards makes the language hard to learn because it seems unnatural. 

Adding features without replacing current features would get the best of both.

Sorry if this has been debated before. I did a quick search but didn't see anything.

Aaron

[Matthew Spencer]

I also agree. Having a match and switch also helps when updating large codebases.

[j...@justinfront.net]

The reason for an RC is so that haxe3 can be tweaked before full release maybe this should be changed asap, early adopters will accept the change it's just a simple search and replace in any already ported code.

It is new users haxe must consider most.

+1 for Match and Switch version.

[Mike Welsh]

This is confusing for users of dynamic languages that allow non-constant cases, such as AS3/JS. These languages view switches as a glorified if/else chain. Other languages like C, and particularly functional languages, don't allow this, so I don't think it's very unusual.

I feel like it's late in the release cycle for a big change to this behavior. And who wants to add yet another keyword, anyway? ;)

The real issue is that the errors and warning are completely unhelpful. The compiler should detect when a non-constant case is used (or when a pattern variable shadows an outer variable), and provide a helpful message explaining that Haxe doesn't work that way, use if...else instead. This should help clear up any confusion!

I created an issue here: https://code.google.com/p/haxe/issues/detail?id=1720

[clemos]

Actually I didn't think about introducing a new keyword... but rather about just allowing non-constant cases.

I'm probably missing something, but I don't really see how this could interfere with the new features...

What if the compiler just "converted" non constant value to "case _ if( a == b ):" under the hood ?

--

[Luca]

On Saturday, April 20, 2013 11:23:29 AM UTC+1, clemos wrote:

Actually I didn't think about introducing a new keyword... but rather about just allowing non-constant cases.

I'm probably missing something, but I don't really see how this could interfere with the new features...

What if the compiler just "converted" non constant value to "case _ if( a == b ):" under the hood ?

The problem is that:

var a = 10;
switch (x) {
   case a: ..
   default:
}

the case a is already well defined as meaning, match anything, and put the value of x into 'a'

[clemos]

Maybe it would make sense to just consider making such cases (when using variables defined in scope) work just like before (or convert to "case _ if( x == a )") ?

Also I'm not sure I see how "match anything, put the of value of x into 'a'" is useful in such situations as you can simply use "x" in "default" or in "case _", can't you ?

[Simon Krajewski]

Am 20.04.2013 12:47, schrieb clemos:
> Maybe it would make sense to just consider making such cases (when
> using variables defined in scope) work just like before (or convert to
> "case _ if( x == a )") ?
> Also I'm not sure I see how "match anything, put the of value of x
> into 'a'" is useful in such situations as you can simply use "x" in
> "default" or in "case _", can't you ?

It's useful for this:

switch(someCalculation()) {
...
case result:
}

Simon

[Heinz Hölzer]

Instead of introducing a new keyword how about allowing the classic
switch through metadata to ease the conversion of haxe2 code.

var x = @:classic switch (1+2) {
case 1: 8;
case 2: 9;
case 3: 10;

[Simon Krajewski]

Am 20.04.2013 15:18, schrieb Heinz H�lzer:
> Instead of introducing a new keyword how about allowing the classic
> switch through metadata to ease the conversion of haxe2 code.
>
> var x = @:classic switch (1+2) {
> case 1: 8;
> case 2: 9;
> case 3: 10;
> }

I suggested pretty much that a while ago:
https://code.google.com/p/haxe/issues/detail?id=1383

Simon

[Heinz Hölzer]

i just checked it and it seems that scala also allows a classical switch
through metadata:

http://www.scala-lang.org/api/current/index.html#scala.annotation.switch

which could look like this in haxe:

var x = switch (@:classic 1+2) {

case 1: 8;
case 2: 9;
case 3: 10;
}

we should maybe look at this as a real feature and not just as a
"haxe2-transition"-syntax like in the issue you mentioned.

best,
h

[Mike Welsh]

I like the metadata solution, alongside the better warnings/errors pointing to the use of the metadata.

[clemos]

Ok, why not :)

Isn't it possible to "switch( var result = someCalculation() ){ default: trace(result); } ?

Or introduce "switch( someCalculation() ){ default result : ... }" ? 

But then, once again, I thought we could introduce a difference between existing identifiers in one hand ("normal" variable cases), and non-existing identifiers , like "result" in your example.

Or use $result or such convention to have a clear distinction between capturing patterns and actual variables / values.

Also I didn't have the time to test, but Juraj seemed to say that the inline static variables are considered constant values, which IMHO brings even more confusion and unexpected behaviours:

public var b = "foo";

public inline var a = "bar";

...

switch( x ){

   case a : // a exists as inline static = considered a constant

   case b : // b not being inline, this matches all other values ... 

}

As for what Mike said about AS3/JS vs C, I believe Haxe has always tried to follow ECMAScript.

I'm not an expert, but I believe this breaks it pretty completely rather than "extending" it with additional features.

Also I don't really like the metadata solution.

To me the point is more to polish the new feature that to support two different constructs.

Regards,

Clément

[Simon Krajewski]

Am 20.04.2013 18:39, schrieb clemos:

On Sat, Apr 20, 2013 at 1:52 PM, Simon Krajewski <si...@haxe.org> wrote:

Am 20.04.2013 12:47, schrieb clemos:

Maybe it would make sense to just consider making such cases (when using variables defined in scope) work just like before (or convert to "case _ if( x == a )") ?
Also I'm not sure I see how "match anything, put the of value of x into 'a'" is useful in such situations as you can simply use "x" in "default" or in "case _", can't you ?

It's useful for this:

switch(someCalculation()) {
    ...
    case result:
}

Ok, why not :)

Isn't it possible to "switch( var result = someCalculation() ){ default: trace(result); } ?

Or introduce "switch( someCalculation() ){ default result : ... }" ?

I prefer to follow the ML-style here instead of introducing some weird syntax for specific cases. After all, "case a" just a particular case of variable capture.

But then, once again, I thought we could introduce a difference between existing identifiers in one hand ("normal" variable cases), and non-existing identifiers , like "result" in your example.

Or use $result or such convention to have a clear distinction between capturing patterns and actual variables / values.

Also I didn't have the time to test, but Juraj seemed to say that the inline static variables are considered constant values, which IMHO brings even more confusion and unexpected behaviours:

public var b = "foo";

public inline var a = "bar";

...

switch( x ){

   case a : // a exists as inline static = considered a constant

   case b : // b not being inline, this matches all other values ... 

}

How is this confusing? It's consistent with usual inline variable behavior.

As for what Mike said about AS3/JS vs C, I believe Haxe has always tried to follow ECMAScript.

I'm not an expert, but I believe this breaks it pretty completely rather than "extending" it with additional features.

Also I don't really like the metadata solution.

To me the point is more to polish the new feature that to support two different constructs.

It's pointless to discuss this, we will not introduce a new keyword this late in the release cycle. I'm sorry if it breaks parts of your code, but we conciously made the decision to enforce constant patterns. It's a fair limitation with simple workarounds, and having pattern matching is surely worth it.

Simon

[clemos]

On Sat, Apr 20, 2013 at 6:57 PM, Simon Krajewski <si...@haxe.org> wrote:

Am 20.04.2013 18:39, schrieb clemos:

On Sat, Apr 20, 2013 at 1:52 PM, Simon Krajewski <si...@haxe.org> wrote:

Am 20.04.2013 12:47, schrieb clemos:

Maybe it would make sense to just consider making such cases (when using variables defined in scope) work just like before (or convert to "case _ if( x == a )") ?
Also I'm not sure I see how "match anything, put the of value of x into 'a'" is useful in such situations as you can simply use "x" in "default" or in "case _", can't you ?

It's useful for this:

switch(someCalculation()) {
    ...
    case result:
}

Ok, why not :)

Isn't it possible to "switch( var result = someCalculation() ){ default: trace(result); } ?

Or introduce "switch( someCalculation() ){ default result : ... }" ?

I prefer to follow the ML-style here instead of introducing some weird syntax for specific cases. After all, "case a" just a particular case of variable capture.

My whole point is "weird syntax" (case _ if ( ... ) ) has now to be used for very common cases (AS3/JS/ECMAScript style switch/case constructs),

while "simple syntax" now corresponds to pretty advanced features (ML-style pattern matching).

 

But then, once again, I thought we could introduce a difference between existing identifiers in one hand ("normal" variable cases), and non-existing identifiers , like "result" in your example.

Or use $result or such convention to have a clear distinction between capturing patterns and actual variables / values.

Also I didn't have the time to test, but Juraj seemed to say that the inline static variables are considered constant values, which IMHO brings even more confusion and unexpected behaviours:

public var b = "foo";

public inline var a = "bar";

...

switch( x ){

   case a : // a exists as inline static = considered a constant

   case b : // b not being inline, this matches all other values ... 

}

How is this confusing? It's consistent with usual inline variable behavior.

It's just confusing for people who are not familiar with ML programming, which I believe is a huge majority of the current Haxe user base...

I can't believe I'm the only one to consider both a and b values in this case, wether they are inlined or not.

 

As for what Mike said about AS3/JS vs C, I believe Haxe has always tried to follow ECMAScript.

I'm not an expert, but I believe this breaks it pretty completely rather than "extending" it with additional features.

Also I don't really like the metadata solution.

To me the point is more to polish the new feature that to support two different constructs.

It's pointless to discuss this, we will not introduce a new keyword this late in the release cycle. I'm sorry if it breaks parts of your code, but we conciously made the decision to enforce constant patterns. It's a fair limitation with simple workarounds, and having pattern matching is surely worth it.

It's really not about my code, which I did indeed fix pretty easily.

It's rather about Haxe changing strategy, moving from "popular" ECMAScript-like language to advanced ML-style language.

I really feel this move is too bold, given Haxe gains most of its popularity among AS3 and JS developers...

If Haxe is to become the new Scala, I'm afraid it'll become even more difficult to seduce new users than it is already, which I feel is really critical right now...

I'm not at all against introducing new, advanced, ML-style features, I understand the power of pattern-matching and all.

I'm not even against rewriting code after each Haxe release (even third party code...).

But dropping one of Haxe's biggest qualities (syntax familiarity, reasonable learning curve, etc) along the way is just something else.

Regards,

Clément

 

Simon

[Greg Dove]

I think the points about ecmascript vs. haxe 3 switch are valid. Much more so than the issue of broken haxe 2 code, and I don't think removing the statement about similarity to ecmascript from the documentation fixes what I consider to be an underlying concern: will the 'strange/exotic nature' of this new feature impede Haxe adoption?

It's easy when you're close to the language to appreciate it's power. But if Haxe truly has a goal of 'world domination', then the language also has to be 'accessible' for new users. By which I mean easy to grasp.

I love the power of the new switch, and am comfortable with it now that I understand it (messing about a bit with ocaml certainly helped!). But I do think that this advanced feature will be daunting and unfamiliar to new users. 

I've run a couple of Haxe intro sessions in the past for as3 devs, and I can see this being something that would take a whole bunch more time to explain, it will be far from an intuitive step forward for them I think. Having the 'classic' switch available by some means (a 'lite' version, where they can't code into the advanced capture/matching syntax by mistake) alongside the more advanced version addresses this and gives new users a stepping stone approach so they can 'graduate' to the advanced switch later on. Doing it with metadata feels wrong, but is better than not having it available at all, I think.

/2cents

Greg Dove
Dove Software Development Ltd
http://greg-dove.com

--

[Andy Li]

I think the current pattern matching behavior of switch is good, and it requires only minor changes to existing code.

And for new user adoption, I do think it is important, which attracting more ML-style hard-core programers isn't a bad thing.

Best,

Andy

[Greg Dove]

On Sun, Apr 21, 2013 at 6:32 AM, Andy Li <an...@onthewings.net> wrote:

I think the current pattern matching behavior of switch is good, and it requires only minor changes to existing code.

I agree, the issue is not with 'broken haxe2 code'

And for new user adoption, I do think it is important, which attracting more ML-style hard-core programers isn't a bad thing.

Also agree. But I think that is automatic with the new feature, which is closer to ocaml for example. My concern is for what I assume to be the *much* larger numbers of non 'ML-style hard-core programmers' who may struggle with this at first. If we had a strategic goal to focus more on the ml style programmers and less on the javascripters, for example, then I am completely wrong.

[Juraj Kirchheim]

I think this is the wrong way of looking at things. The strategic goal is neither to be "ML-style hard-core" or "ECMAScript cargo-cult" or whatever. Haxe is not just an extended portable dialect of some other language. It is a language of its own, with its own feature set. The strategic goal is to provide a well designed language, where the features complement each other, because that's what you need in the long run.

Haxe 3 is quadruple-rainbow-awesome and as a Haxe user, that's what I care about most. If some JavaScripter needs to get his head around a couple of things to properly use Haxe, then I am actually happy for them. That being said, if you look at the current Haxe feature set, there's ample amounts of things that will need *much* longer than pattern matching to really sink in if JavaScript is all you know.

Regards,

Juraj

[Jason O'Neil]

Alright... I hate to be that guy, but: http://haxememes.tumblr.com/post/42315290417

Here is an implementation that uses macros to transform a switch statement into a set of if/elseif/else statements that will behave in more or less the ecmascript way. 

https://gist.github.com/jasononeil/5429516

ClassicSwitch.hx - a macro which takes a switch statement and turns it into an if/elseif/else chain. This is useful if you want traditional ecmascript "switch" behaviour, not the kick-ass haxe pattern matching. Times this is useful: if one of your cases is a variable:

option1 = "Something1";
option2 = "Something2";
switch (someVar)
{
    case option1: trace ("do something 1");
    case option2: trace ("do something 2");
}

This doesn't work with pattern matching, because option1, option2 are seen as capture variables. With this macro, you could do:

option1 = "Something1";
option2 = "Something2";
ClassicSwitch.from(switch (someVar)
{
    case option1: trace ("do something 1");
    case option2: trace ("do something 2");
});

... and things will behave as expected.

Some quick tests in the Main.hx below. Run with haxe -x Main.hx, in Haxe 3RC or above.

If this is going to be a common stumbling point (and it might be) then I think more descriptive error messages is the place to start.  If that's still seen as too difficult for people coming from JS / ActionScript, then perhaps we can include a macro similar to this in the Standard Library or in the HxCompat haxelib and point people to it.

Also, a guide like this: http://www.nme.io/developer/guides/actionscript-developers/ I think is the perfect way to explain the differences between Ecmascript "switch" and Haxe3 pattern matching.

Jason

 

--

[Greg Dove]

@Juraj

It's impossible to disagree with "Haxe 3 is quadruple-rainbow-awesome" (I definitely agree). But I think we should help make sure that target users experience at least the first rainbow when they try Haxe - and they can see the other rainbows as a tantalising lure. 

I know that Haxe is not currently in danger of obscurity through purity, but just because it's popular with those of us who currently use it doesn't mean it's popular. Not yet, anyway. I'd like to think that Haxe can maintain its approachability while adding even more rainbows. The example being discussed is a small thing really - in isolation. But it seems that at least a few people have quite different views about it. I can say that mine are driven by my belief that Haxe should not evolve to be less approachable for target users. And from what I have read, it appears to me that javascripters/actionscripters remain important groups for growth.

I would certainly like a more explicit understanding of where Haxe is focusing on growth, because my understanding at the moment is only gleaned/derived from what I have read in fragments across multiple sources (including haxenext), and not from any official statement. What might really help in terms of shared understanding/alignment is if, post Haxe 3.0, the Foundation makes some decisions that they can reveal about strategy for key segments of the market that represent the most important areas  for growth, and guide marketing programmes. That will help the community (I think it will - it will certainly help me!) understand and align with things. Hopefully that will happen. Until then I will cease and desist!

@Jason

That's sounds great - sounds like it might be a more 'safe' option to offer to new users, "switch in Haxe is more advanced than you're used to with language x, but you can start by using a version that will work like what you already know". It's good because it provides familiarity and also an obvious clue that they can graduate to a more advanced version when they're comfortable doing so. I personally prefer it to the metadata approach, although perhaps the metadata approach would have some benefits for those porting haxe2 libraries or codebases.

Greg Dove
Dove Software Development Ltd
http://greg-dove.com

[Zjnue Brzavi]

Hi,

I've recently updated all the Haxe PureMVC libraries to support both Haxe 2 & 3 to help smooth the transition towards the imminent Haxe 3 release.

While I'm also very thankful for all the fantastic updates, adding expressiveness and power to the language, I would also like to guard against alienating the ECMA-school potentials.

Right now, there is no pretty way to support both Haxe 2 and Haxe 3 switches via conditional compilation for a particular usage instance.

This lead me to fall back to IF statements for the PureMVC libraries, as was discussed with Cliff Hall here:
https://github.com/PureMVC/puremvc-haxe-util-pipes/pull/1#issuecomment-16710522

I think if there is no easy way to specify old switch behaviour on either project-level (via a compiler flag) or switch-instance level (via metadata), it may necessitate similar lengthy explanations as above and upset some potential new users.

Zjnue

[Simon Krajewski]

Am 22.04.2013 23:43, schrieb Zjnue Brzavi:

Hi,

I've recently updated all the Haxe PureMVC libraries to support both Haxe 2 & 3 to help smooth the transition towards the imminent Haxe 3 release.

While I'm also very thankful for all the fantastic updates, adding expressiveness and power to the language, I would also like to guard against alienating the ECMA-school potentials.

Right now, there is no pretty way to support both Haxe 2 and Haxe 3 switches via conditional compilation for a particular usage instance.

This lead me to fall back to IF statements for the PureMVC libraries, as was discussed with Cliff Hall here:
https://github.com/PureMVC/puremvc-haxe-util-pipes/pull/1#issuecomment-16710522

"

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):
"

The former version should still work if NORMAL and SET_PARAMS are static inline variables.

Simon

[Zjnue Brzavi]

"

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):
"

The former version should still work if NORMAL and SET_PARAMS are static inline variables.

Interesting thanks. They are static inline variables and it was not working at the time, but my Haxe nightly may have been somewhat old.

Let me grab the latest and get back to you.

[Tarwin Stroh-Spijer]

I must say I'm completely confused as to what this means. Does this mean that "switch" as used in haxe 2 is completely changed? Can I not anymore do this?

var x = switch(y){

  case "a": "aa";

  case "b": "bb";

}

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
cell: +1 650 842 0920
_______________________

--

[Simon Krajewski]

Am 22.04.2013 23:55, schrieb Tarwin Stroh-Spijer:
> I must say I'm completely confused as to what this means. Does this
> mean that "switch" as used in haxe 2 is completely changed? Can I not
> anymore do this?
>
> var x = switch(y){
> case "a": "aa";
> case "b": "bb";
> }

That works fine, people are just overreacting a bit. ;)

The added restriction is that case expression must be constant, so e.g.
this does not work anymore:
case identifier:
case SomeClass.SomeNonInlineField:

Simon

[Zjnue Brzavi]

I've rebuild Haxe from SVN just now and the error seems to persist.

From the referenced PureMVC project:
https://github.com/PureMVC/puremvc-haxe-util-pipes

Please make these changes to src/org/puremvc/haxe/multicore/utilities/pipes/plumbing/Filter.hx [1]:

(checked: all the switch constants:
case Message.NORMAL:
case FilterControlMessage.SET_PARAMS:
case FilterControlMessage.SET_FILTER:
case FilterControlMessage.BYPASS:
case FilterControlMessage.FILTER:

..are inline statics)

In the project root, if you run "haxe build.hxml", you will get the following compiler error:

$ haxe build.hxml
src/org/puremvc/haxe/multicore/utilities/pipes/plumbing/Filter.hx:80: characters 7-21 : Constant expression expected

Is there something else not specified correctly?

Thanks,

Zjnue

[1]
diff --git a/src/org/puremvc/haxe/multicore/utilities/pipes/plumbing/Filter.hx b/src/org/puremvc/haxe/multicore/utilities/pipes/plumbing/Filter.hx
index 8bbb988..75ca6e5 100644
--- a/src/org/puremvc/haxe/multicore/utilities/pipes/plumbing/Filter.hx
+++ b/src/org/puremvc/haxe/multicore/utilities/pipes/plumbing/Filter.hx
@@ -73,9 +73,11 @@
     {
         var outputMessage: IPipeMessage = null;
         var success: Bool = true;
-        var messageType: String = message.getType();
+        //var messageType: String = message.getType();
        
-        if (messageType == Message.NORMAL)
+        switch (message.getType()) {
+        //if (messageType == Message.NORMAL)
+        case Message.NORMAL:
         {
             // Filter normal messages
             try
@@ -95,7 +97,8 @@
                 success = false;
             }
         }
-        else if (messageType == FilterControlMessage.SET_PARAMS)
+        case FilterControlMessage.SET_PARAMS:
+        //else if (messageType == FilterControlMessage.SET_PARAMS)
         {
             // Accept parameters from control message
             if (isTarget(message) )
@@ -107,7 +110,8 @@
                 success = output.write( outputMessage );
             }
         }
-        else if (messageType == FilterControlMessage.SET_FILTER)
+        case FilterControlMessage.SET_FILTER:
+        //else if (messageType == FilterControlMessage.SET_FILTER)
         {
              // Accept filter function from control message
             if ( isTarget( message ) )
@@ -119,7 +123,8 @@
                 success = output.write( outputMessage );
             }
         }
-        else if (messageType == FilterControlMessage.BYPASS)
+        case FilterControlMessage.BYPASS:
+        //else if (messageType == FilterControlMessage.BYPASS)
         {
             // Toggle between Filter or Bypass operational modes
             if ( isTarget( message ) )
@@ -131,7 +136,8 @@
                 success = output.write( outputMessage );
             }
         }
-        else if (messageType == FilterControlMessage.FILTER)
+        case FilterControlMessage.FILTER:
+        //else if (messageType == FilterControlMessage.FILTER)
         {
             if ( isTarget( message ) )
             {
@@ -142,12 +148,17 @@
                 success = output.write( outputMessage );
             }
         }
-        else
+        #if haxe3
+        case _:
+        #else
+        default:
+        #end
+        //else
         {
             // Write control messages for other fittings through
             success = output.write( outputMessage );
         }
-       
+        }
         return success;           
     }
    

[Simon Krajewski]

Please file an issue, it could be related to MESSAGE having a value of BASE + 'normal/'.

Simon

[Zjnue Brzavi]

Sure, thanks, it would be great to have this working for the final release.

--

[Zjnue Brzavi]

Please file an issue, it could be related to MESSAGE having a value of BASE + 'normal/'.

http://code.google.com/p/haxe/issues/detail?id=1732

[Nicolas Cannasse]

[...]

> I would certainly like a more explicit understanding of where Haxe is
> focusing on growth, because my understanding at the moment is only
> gleaned/derived from what I have read in fragments across multiple
> sources (including haxenext), and not from any official statement. What
> might really help in terms of shared understanding/alignment is if, post
> Haxe 3.0, the Foundation makes some decisions that they can reveal about
> strategy for key segments of the market that represent the most
> important areas for growth, and guide marketing programmes. That will
> help the community (I think it will - it will certainly help me!)
> understand and align with things. Hopefully that will happen. Until then
> I will cease and desist!

At the Haxe Foundation we of course take into account the fact that Haxe
has to remain a language easy to access, learn and read. That mean that
we are very careful about adding new fancy language features that might
be useful only for a small part of the existing user base while
alienating a bigger set of existing or potential users.

But when we find that something integrates well in the language and can
be easily understandable - if not familiar - by new users, then we
seriously consider adding it.

That was the case for pattern matching, which is just an extension of
the previously accepted syntax in Haxe.

In 2.0, you could match the patterns using :
- constant values "a", 0, false
- enums Red, Green, Alpha(amount)

In 3.0 we have enhanced the amount of patterns you can use and added
"if" conditions that allows some better filtering.

We don't think that this overly complicates the language or makes it
obscure by newcomers. However it might sometime trigger errors that
puzzles users. In that case we might work towards handling the most
common happening cases in order to display a more readable error.

Best,
Nicolas

[clemos]

Hi,

Of course there is always a macro for that ;)

I've also given a try to the macro approach.

My goal was not really to re-make a pure classic switch, but to support both pattern matching and "old school" switch.

Here it is :

https://gist.github.com/clemos/5443026

It's largely untested and quite surely doesn't cover all cases, 

but it might give a more precise idea of what I'd consider an even better switch/case construct, supporting both simple constructs and advanced pattern matching.

It checks all cases and uses Context.typeof to see if the case is a pattern (unknown identifiers = leaves it as is) or a value / identifier.

If it's considered a value / known identifier, it will change the case to "case _ if( switchExpr == caseExpr ) :" to avoid "constant expected", "unrecognized pattern" and such.

If it's a literal (1, "foo"), it will also remain untouched.

switchExpr is evaluated before switch itself so it's evaluated only once.

For now, inline statics are considered values / identifiers like any other and thus are transformed to guards too, as I don't think I can know if an expression will be inlined to a constant or not.

I'm not sure the side effects this might have.

It will probably disallow completeness checks and duplicate pattern checks (don't know if it's clear).

Also patterns like [a,b] where a is a known identifier and b an unknown identifier (a capture) will be ignored, which is not 100% consistent.

Obviously this little experiment brings more questions and problems to solve :), 

but I still think it might be further polished and seen as a good compromise.

What do you think ?

Regards,

Clément

[clemos]

Hi again,

I've just changed it so it's slightly more consise:

"case a :" will be translated to "case __result__ if ( a == __result__ ) : " to avoid adding switch expression evaluation before the actual switch (this is already done by the compiler).

Regards,

Clément