Issue Details (XML | Word | Printable)

Key: FDT-338
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: FDT Team
Reporter: Adrian
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

Referencing some class in a class with an identically named member does not show up as an error

Created: 28/Mar/09 01:10 PM   Updated: 22/Jun/12 07:01 PM
Component/s: Core (Deprecated)
Affects Version/s: 3.1.1
Fix Version/s: None
Security Level: public

Time Tracking:
Not Specified

Environment: OS X & Windows
Issue Links:

Review Type: Review by Product Owner

 Description  « Hide
got this class:

import flash.geom.Point;

public class FooBar { public var Point:Point; }

Not a very common issue, I guess, for most people, but we have lots of classes with .net-compatible signatures, thus this happens frequently for us. The mxmlc-compiler is not able to correctly identify the class, but this does not show up as error in fdt.

The compiler errors with: Spalte: ... Fehler: Typ wurde nicht gefunden oder war keine Kompilierungszeit-Konstante: Point.

Correct implementation is:

import flash.geom.Point;

public class FooBar { public var Point:flash.geom.Point; }

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Maxim Zaks added a comment - 06/Apr/09 02:51 PM
We added a new ErrorMarker "ambiguous variable name"
That shows up if the variable name is same as visible Class name or Function name.
The Error is set on Warning per default.

Adrian added a comment - 06/Apr/09 03:32 PM
I can't yet test it, but I believe this does not really fix this issue. If I understand correctly, you get a warning that you are doing something that might cause yourself problems, which is great for mostly everbody(but mostly everybody doesn't have this issue anyways). In our case I now that what I'm doing causes me this ambiguity, I know how to handle it and I know as well that there is now way for me to avoid this ambiguity since I cannot rename the variable. Hence, I will probably deactivate this warning for me, since I will get hundreds of new warnings that don't tell me anything new.

The real problem itself is not detected by this marker, that is, you need to use fully-qualified class-names if you want to reference the class instead of the variable. Same applies to getters/setters as well, btw.

Maxim Zaks added a comment - 06/Apr/09 04:03 PM
so what would be the reight Error Highlight?

Type Point have to be full qualified because of field Point?

Adrian added a comment - 06/Apr/09 04:22 PM
This would probably be the most descriptive and helpful error-message, correctness is being lost somewhere on the line between syntax and semantics. The output of mxmlc is very misleading but nevertheless in some way correct.

To me this looks like a incosistency of your as3-parser with the mxmlc-parser in the name-resolver. If you fix the bug there this will show up as "Could not resolve type reference ..."-error anyways. This would be a correct error message and be in line with mxmlc as well.

Alan K (Deprecated) added a comment - 28/Feb/12 04:59 PM
Hey guys,

In looking at this, I see two fixes here. FDT should have the warning be an error by default.

There is also a missing error in this statement:

Point = new Point;

I'm going to close this ticket because it's been split up into two, more specific, bugs in the parser.