Issue 44 - Haxe importing flash .swfs broken - haxe

[issuesbot]

[Google Issue #44 : https://code.google.com/p/haxe/issues/detail?id=44]
by [email protected], at 14/01/2010, 03:00:12
What steps will reproduce the problem?

The following Breaks.as (attached)

package { 
    public class Breaks {
        static public function f() : void {
        }
        public function f() : void {
        }
    }
}

1. (optional results .swf attached) Compile into Breaks.swf (attached),
   using Adobe Flex "mxmlc Breaks.as".
2. C:\workspace\flashdemo\ActionScriptTests>haxe --gen-hx-classes
   Breaks.swf
   import Breaks;
3. C:\workspace\flashdemo\ActionScriptTests>cd hxclasses
4. C:\workspace\flashdemo\ActionScriptTests\hxclasses>haxe Breaks.hx
   Breaks.hx:4: characters 8-28 : Same field name can't be use for both
   static and
   instance : f

What is the expected output? What do you see instead?

Haxe should compile ok
Haxe breaks in haxe compiler.

What version of the product are you using? On what operating system?
2.0.4 on Windows XP.

Please provide any additional information below.

Haxe importing flash .swfs in broken, it generates bad .hx from the .swf:
In Actionscript you may have a method with the same name as a static
method in the class. This is not valid in Haxe but haxe --gen-hx-classes
outputs a .hx that will not compile. FieldBreaks.as/FieldBreaks.swf have
the same problem but with fields rather than methods.

Please fix ASAP as I have a project that depends on importing .swfs like
those attached.

Yours Sincnerely,

Hank Inaworken.

[issuesbot]

[comment from [email protected], published at 17/01/2010, 22:10:27]
[Reply from Justin Donaldson on Haxe mailing list]
Date: Wed, 13 Jan 2010 01:35:11 -0500

Hi Hank,

I'm pretty sure the behavior here is correct, or at least not fixable. The
--gen-hx-classes essentially does a format translation, but it's far from
foolproof. There are still plenty of things that can prevent the translated
code from compiling. It is the discretion of the programmer to work around
issues like yours, because there really isn't a best way for handling it
automatically.

Fixing it would involve renaming one of the field/method names (which one?),
which could potentially cause naming conflicts. Then all the external class
references to this function must be changed, etc. There's probably some
references (involving reflection) that the compiler couldn't possibly
find.

Also, if you want Nicolas or one of the main dev's to find this issue
faster, it's better to submit a bug report to the issue log on google code:
http://code.google.com/p/haxe/issues/list

-Justin

[issuesbot]

[comment from [email protected], published at 17/01/2010, 22:14:31]
[Reply from Nicolas Cannasse on Haxe mailing list]
Date: Wed, 13 Jan 2010 10:01:07 +0100

This is a limitation of haXe that can't be removed. You will have to
comment one of the two fields and then if you want to access it use
"Reflect.field" or "untyped".

Nicolas

[issuesbot]

[comment from [email protected], published at 18/01/2010, 04:55:30]
Could we have the haXe not output the static method or field where there is a
conflict (an instance field or method with the same name), or even better output a
comment saying it was omitted?

Reflect.callMethod(Breaks, Reflect.field(Breaks, "f"), []));

works calling the commented out static field (field of the class, not the field of
an instance).

Hank.

[issuesbot]

[comment from [email protected], published at 24/01/2010, 14:33:12]
A comment have been added in front of static fields when a non static field has the
same name in the same class. It will still fail when a static method with the same
name has a superclass field gets generated.

[issuesbot]

[comment from [email protected], published at 26/01/2010, 21:40:34]
Are you sure this is the case? Haxe doesn't mind if the conflict is across different
classes.

Attached are Breaks2Base.hx and Breaks2Sub.hx which have the same named field as a
static in the superclass and an instance field in the subclass, haxe Breaks2Sub.hx
compiles ok.