Haxe (From: Java > Scala -> new thread: GUI for D)

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:jblhn8$1vis$1 at digitalmars.com...
> "Adrian" <adrian.remove-nospam at veith-system.de> wrote in message 
> news:jbkkpf$cut$1 at digitalmars.com...
>> Am 05.12.2011 18:56, schrieb Nick Sabalausky:
>>>
>>> Why did I write the whole thing from scratch in D as a separate tool,
>>> instead of just adding D support to the official Haxe codebase? Ehh,
>>> possibly-questionable reasons:
>>>
>>> 1. Because I looked at Haxe's source and decided I didn't feel like 
>>> figuring
>>> out OCaml before getting started :/
>>>
>>
>> yes OCaml is another beast. My idea was to take the source of Hugh
>> Sandersons C++ target and adopt it to D. For me, D is a much more
>> logical target for haXe, because many of the language features fit
>> better together. The problem I see with your solution is, that haXe
>> evolves very fast and a D target written in OCaml would benefit from
>> this, whereas a target written in D is always behind.
>>
>
> Yea, that is definitely the downside of my approach. OTOH, Haxe still 
> doesn't evolve as fast as, say, D. And I'm optimistic that once I have it 
> 100% working, updates shouldn't be too difficult. Most of the changes in 
> each Haxe release are either in the std lib, neko-related, or bug-fixes, 
> none of which would be applicable to HaxeD (as far as the std lib, HaxeD 
> will have a copy of the std lib that may add some "#if d" directives where 
> applicable, and those would need to get merged wih each Haxe release, but 
> that shouldn't be too hard).
>

There is another upside to my approach, though: It gives me the ability to 
add optional features without Cannasse's approval. Sometimes he can 
be...(how can I say this diplomatically?)...a bit stubborn in refusing to 
even consider or discuss reasonable requests. He seems to like his "Denied 
Because I Said So" stamp ;). Couple off the top of my head examples:

http://code.google.com/p/haxe/issues/detail?id=106 Forum thread links have 
JS that screws up "open link in new tab/window"

http://code.google.com/p/haxe/issues/detail?id=105 Assigning from a Dynamic 
silently subverts type system and corrupts var.

Note that first one, #106, is NOT my usual "X requires JS" complaint. This 
is something that breaks standard browser behavior *with* JS on, and is a 
trivial fix with no downside (at least none that he was willing to actually 
share). Of course, that's just unrelated website stuff, but...

That #105 in particular is pretty nasty. Haxe supports static typing and 
also has a Dynamic type. But take a look at this:

    var dyn:Dynamic = "foo";
    var i:Int;  // Statically-typed **INTEGER**!!
    i = dyn;

Guess what? Not only does the compiler accept that, but there is no 
runtime-check either. My *statically-typed integer* now contains a *string* 
("foo")!!  Yes, seriously. And with *no* explicit casts or "unsafe" or 
anything. Of course, the fun doesn't stop there:

    dyn = "5";
    i = dyn;
    i += 10; // Looks like integer addition
    trace(i); // Wheee!!! Output: 510

Granted, one could argue that you should be able to this without any 
run-time baggage if you chose to (for instance, if you *know* that dyn is 
really an Int). But Haxe ALREADY has "Unsafe Cast" which DOES EXACTLY THAT!:

    // From the official docs on Unsafe Cast:
    // "...the cast call will not result in any runtime check,
    // but will allow you to "loose" one type."
    i = cast dyn;

After I explained all of that to commenters #1 and #3, Cannasse pulled out 
his "Denied" stamp along with a message that clearly misunderstood much of 
the issue.

</rant>

So anyway, with my own Haxe implementation, I can just add an optional 
"-sane" switch to enable either a runtime or compile-time check...And nobody 
can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!!