0

I'm trying to cross compile an existing flash app written in haxe into javascript using openfl and haxe.

Under flash I can do the following:

class foo
{
    var bar : Int;

    public function new()
    {
        trace(bar); //under flash prints 0, under javascript undefined
    }
}

When compiling to javascript instead of 0, i get Undefined.

My questions is can I either make the compile print warnings/error if a member variable is left uninitialized by the constructor.

Even better can I make haxe I make it so haxe will initialize them for me in js to 0.

Same story with Bool = false, Float = 0 etc, I haven't tested but probably with Object = null also.

The app has 144 classes, and over 20k lines of code. Finding and adding explicit initializers manually will take a ton of time, which is why I'm looking for alternatives.

tesract
  • 53
  • 10
  • 3
    This is the documented behaviour: http://haxe.org/manual/types-nullability.html - basically on "Dynamic" platforms (JS, Neko, PHP, Python) the default value will always be null. @Nico's answer was correct - just initialize it to zero when you declare it, and you will be safe. – Jason O'Neil Jun 14 '14 at 03:46

3 Answers3

4

Why dont you just do: var bar:Int = 0; Unless you have a specific situation where it really matters (which I have run into) it shouldnt be a big deal:)

Nico
  • 94
  • 9
  • The existing haxe source has 144 classes, and over 26k lines of code. I'd very much like to avoid having find every place that need an =0, or an =false manually. – tesract Jun 16 '14 at 18:26
0

In case some one else has this question. I solved the issue by using sed and a regular expression to find and replace all uninitialized variables in my source tree.

From the root of the source tree I ran the following commands under ubuntu.

find . -print0 -name "*.hx" | xargs -0 -n1 sed -i -e "s/\(var [^:]\+:\s*Int\s*\);/\1 = 0;/g"
find . -print0 -name "*.hx" | xargs -0 -n1 sed -i -e "s/\(var [^:]\+:\s*UInt\s*\);/\1 = 0;/g"
find . -print0 -name "*.hx" | xargs -0 -n1 sed -i -e "s/\(var [^:]\+:\s*Bool\s*\);/\1 = false;/g"
find . -print0 -name "*.hx" | xargs -0 -n1 sed -i -e "s/\(var [^:]\+:\s*Float\s*\);/\1 = 0;/g"
find . -print0 -name "*.hx" | xargs -0 -n1 sed -i -e "s/\(var [^:]\+:\s*[^=]\+\s*\);/\1 = null;/g"

That will replace

var [variableName] : Int;  

with

var [variableName] : Int = 0;

Similar for UInt, Bool, Float. All other types are set to null.

I didn't write one for var [varName]; since there were only 4 instances of that in my source tree.

Unihedron
  • 10,902
  • 13
  • 62
  • 72
tesract
  • 53
  • 10
0

As it was noted before, this is documented: haxe.org/manual/types-nullability.html. The reason is simple: speed.

But there is a couple of things to note.

In javascript you can fix that without loosing speed and with a slight increase in file size. It even makes code run faster actually. You could do that by setting default values to object prototypes, which in turn can be done quite simply by using custom js generator feature.

For the other platforms, there is no such way, I suppose, so the only thing to resort to is dynamic initialization. But fear not! Macros are here for you. It is quite easy to write a macro which would notify you about uninitialized values, and also quite easy to write macro which would initialize them for you.

But to be honest, I don't see much of a problem there, maybe you are overestimating it? I am working with haxe for years, every day, and I never ran in any serious problems with that. Most of time it won't bother you at all since you normally initialize things dynamically, and in cases where you don't, such problems usually take like 5 seconds to fix. Just IMHO of course.

stroncium
  • 1,430
  • 9
  • 8
  • Since I've ran the sed command to initialize everything many of the issues are fixed. The flash app was coded to rely on auto initialization of variables, so in javascript that was causing many subtle bugs. Those are all gone, and now I can focus on fixing things like openfl not implementing flash.display.drawRoundRect. – tesract Jun 23 '14 at 17:50