<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>CuppaDev - Latest Comments in What not to write in haXe</title><link>http://cuppadev.disqus.com/</link><description></description><atom:link href="https://cuppadev.disqus.com/what_not_to_write_in_haxe/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Fri, 01 Aug 2008 16:37:12 -0000</lastBuildDate><item><title>Re: What not to write in haXe</title><link>http://www.cuppadev.co.uk/what-not-to-write-in-haxe#comment-2430215</link><description>&lt;p&gt;Thanks again Nicolas! :)&lt;/p&gt;&lt;p&gt;Great to see all of those quirks fixed. My only criticism would be that Int32 is still not treated as a normal integer type, so code ends up filled with quirky looking "Int32.dothis(Int32.dothat())" statements. Would have thought if you could abstract the whole language onto another, you'd be able to abstract the Int32 as to act as an Int as well.&lt;/p&gt;&lt;p&gt;Regardless, i actually managed to compile hiscumm in haXe 2.0 with very minor modifications. Only problem is, to use the new haxe.Int32 stuff i have to re-do the whole IO code again. Eeek!&lt;/p&gt;&lt;p&gt;Still, i'm very pleased with haXe 2.0, and look forward to future uses of it in production environments. :)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">James Urquhart</dc:creator><pubDate>Fri, 01 Aug 2008 16:37:12 -0000</pubDate></item><item><title>Re: What not to write in haXe</title><link>http://www.cuppadev.co.uk/what-not-to-write-in-haxe#comment-2430214</link><description>&lt;p&gt;You'll be happy to know that with haXe 2.0 release :&lt;/p&gt;&lt;p&gt;- you can now remap packages with --remap flash:noflash (to fix your first problem)&lt;/p&gt;&lt;p&gt;- array bug has been fixed in neko 1.7.1&lt;/p&gt;&lt;p&gt;- there is crossplatform haxe.Int32 support (and crossplatform &lt;a href="http://haxe.io" rel="nofollow noopener" target="_blank" title="haxe.io"&gt;haxe.io&lt;/a&gt; + haxe.io.Bytes as well)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Nicolas</dc:creator><pubDate>Thu, 31 Jul 2008 14:20:39 -0000</pubDate></item><item><title>Re: What not to write in haXe</title><link>http://www.cuppadev.co.uk/what-not-to-write-in-haxe#comment-2430152</link><description>&lt;p&gt;Many thanks for the suggestions, Nicholas! :)&lt;/p&gt;&lt;p&gt;I'm surprised that i didn't figure that sticking the #ifdef'd stuff in Common.hx would be possible with haXe. Still, now i have an excuse to take a second look. :)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">James Urquhart</dc:creator><pubDate>Sun, 02 Mar 2008 00:12:46 -0000</pubDate></item><item><title>Re: What not to write in haXe</title><link>http://www.cuppadev.co.uk/what-not-to-write-in-haxe#comment-2430151</link><description>&lt;p&gt;For imports, you can do the following&lt;/p&gt;&lt;p&gt;// Common.hx&lt;/p&gt;&lt;p&gt;#if flash9&lt;br&gt;typedef Bitmap = flash.display.Bitmap;&lt;br&gt;typedef BitmapData = flash.display.BitmapData;&lt;br&gt;....&lt;br&gt;#else neko&lt;br&gt;typedef Bitmap = noflash.Bitmap;&lt;br&gt;typedef BitmapData = flash.display.BitmapData;&lt;br&gt;...&lt;br&gt;#end&lt;/p&gt;&lt;p&gt;Then from your code you only need to "import Common".&lt;/p&gt;&lt;p&gt;The 115 Array Size is entirely arbitrary, it's just a temporary bugfix for a current Neko compiler issue that will be addressed in next version.&lt;/p&gt;&lt;p&gt;31 bit integers are part of the Neko specification (see &lt;a href="http://nekovm.org)." rel="nofollow noopener" target="_blank" title="http://nekovm.org)."&gt;http://nekovm.org).&lt;/a&gt; It's true that there is no crossplatform Int32 API right now, but that can easily be defined in haXe using inline methods.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Nicolas</dc:creator><pubDate>Sat, 01 Mar 2008 14:24:23 -0000</pubDate></item></channel></rss>