Error #1037 Bug Report, Flash Builder 4.6

[Howitzer21]

I tried reporting this bug through the proper channels, but the link on the page at https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform for filing Flash Builder bugs is not working.  The page it links to is "taking too long to respond".

I'm using Flash Builder 4.6, and I'm getting error #1037.  According to the documentation at http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/runtimeErrors.html, this isn't something that should be happening, and when the programmer doesn't believe the swf has been corrupted, Adobe has requested that they report it.  Even though I feel something like this always justifies the word "corrupted", I don't believe it's been corrupted in this strict of a sense; I'm just building the swf in Flash Builder.  The project itself is fairly simple and doesn't have any out-of-the way configurations.

Take the following line of code in the start class:

m_com.onBWDone = rnd.handleBWDoneResults;

the following code in m_com's class:

private var m_fOnBWDone:Function;

public function set onBWDone(pValue:Function):void

{

    m_fOnBWDone = pValue;

}

and the following code in rnd's class:

public function handleBWDoneResults(... pRest):void

{

     ...

}

The line of code in the starting class is what's throwing the error.  If I comment that line of code out, the error goes away.  If I simply make m_fOnBWDone a public variable, delete the setter, and set the variable's value directly in the starting class, that works too.  But if I try to make it private and then use a trivial public property to set it like that, the error is raised.

@Adobe Please fix this.  Thanks.

[sinious · Accepted solution]

Since this class is assigning functions to a scope and that error will be thrown if you attempt to use 2 methods of the same name, are you certain you're not accidently trying to create 2 methods of the same name in the same scope? If the method name you pass into pValue is already defined in the same scope, it should be thrown.

[Howitzer21]

If I'm following you correctly, no.  I'm just using trivial property syntax without conflicting names in the same scope or anything.  The documentation said this error shouldn't be able to happen if  the swf is uncorrupted.

[Howitzer21]

Well, I take that back.  It is true that the documentation says that this error should not be able to happen when the compiler is working and the swf is uncorrupted.  However it does look like there was a function of the same name as that property in the class, onBWDone.  I don't understand how that should've been able to compile.  But even if that's valid syntax, the documentation said to just report this as a bug if the swf wasn't seemingly corrupted.

[sinious]

The docs say it could be a few things, just one of which is the corrupt portion.

You shouldn't have a method and property with the same name either. In any get/set situation for a private value your private value is typically prefaced just to avoid the collision with the public get/set. For the same reason, colliding, methods and properties should be unique and I am also confused as to how it compiled (although FB just warns you there's an issue and still allows you to proceed).

What you're doing there appears to be highly dynamic, so I really can't say what kind of method names you're assigning with pValue. Nor can the compiler until you send 2 different functions with the same name there and it errors on you. Only you know what functions are being assigned in there, or what you do with it after that.

[Howitzer21]

I didn't mean to use the same name redundantly, but I'm using sealed classes and everything.  Instead of using Events though, I usually just use callbacks by making a variable of type Function and then providing a setter or something.

[sinious]

Did changing the name and keeping your desired class protection level solve your issue?

I get a lot more of this accidental nature in AS2.0 or JavaScript. Functional languages just get you so used to their closure encapsulation it's easy to lose track passing context references back and forth so often. Colissions are almost unavoidable in a team environment.

[Howitzer21]

Yeah.  Thanks for mentioning it; I had no idea that happened or would've compiled.

[sinious]

Glad you're all set, you're welcome and good luck!