[haXe] Some examples that compiles, but should not, and somethat does not, but should.

[Andersen, Søren Frank]

Thanks for the comments. 

Both 1 and 3 did happen for me while doing real programming. It is the kinds of mistakes you do when trying to find out how a language works. :-)

About 5. Here is a revised example:

//
// 5b
//
enum E5 { A5; }
class C5 { 
function f1( e : E5 ) : Int {
	switch( e ) {
		case A5: return 1;
		// Does not compile. It must be replaced with "default:"
		case null: return 0;
	}
}
function f2( e : E5 ) : Int {
	return switch( e ) {
		case A5: 1;
	}
} }

In f1, I think it is better to have "case null:", then "default:" because it will then give compile errors if you forget a enum value. Compile errors for missing enum values in a switch statement is a very nice feature.

Why is "default:" or "case null:" not required in f2? 
In the example calling "f2( null )" will return null.

Regards,
Søren

PS:
I think Haxe is a huge improvement over javascript/ActionScript.

-----Original Message-----
From: haxe-bounces at lists.motion-twin.com [mailto:haxe-bounces at lists.motion-twin.com] On Behalf Of Nicolas Cannasse
Sent: 26. januar 2007 00:04
To: The haXe compiler list
Subject: Re: [haXe] Some examples that compiles, but should not, and somethat does not, but should.

> Hi
> 
> I have had a little fun writing some small examples. 
> 
> I have written my comments in the attached compile.hx file. Please have a look.

Interesting, here's my comments :

1,2,3 : valid points, maybe to fix in the compiler, but rarely happening in the "real world" ;)

4 : the type of the Array is inferred, and is not the minimal type but the first one. Could be improved, I will have a look

5 : you have to handle the "default" case because your enum can be "null" as well

6 : f2 - syntax error
    f3 : currently { } is ambiguous since it can either be the empty block or the empy object. It's currently the empty block. Maybe changing that in the compiler would make sense, but I'm not sure. It's pretty rare to need the empty object anyway since it doesn't have any field.
    f4 : is ok, used in conjonction with Reflect.setField to store
    f6 : does compile, since Dynamic is a Class, and a class is an object, and every object is a subtype of the empty anonymous object (}.
"Dynamic" is a type, the "Dynamic" value is the "Dynamic" class.

7 : f1 - same unification problem than Array, more difficult to fix this one since the intended behavior is less obvious

Nicolas

--
haXe - an open source web programming language http://haxe.org