"Nick Sabalausky" <a@a.a> wrote in message news:jblhn8$1vis$1...@digitalmars.com... > "Adrian" <adrian.remove-nos...@veith-system.de> wrote in message > news:jbkkpf$cut$1...@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!@!!!