Copy link to clipboard
Copied
Hi
Here is my test code for the problem.
package {
import flash.display.Sprite;
// A hérite de Sprite pour pouvoir être utilisée comme classe de document dans le cadre de ce test
public class A extends Sprite {
// Propriété de test
private var _p:uint = 10;
public function get P():uint {
return _p;
}
// Erreur "1000: Référence ambiguë à P." si protected, aucune erreur si public
protected function set P(value:uint):void {
_p = value;
}
// Constructeur
public function A() {
var test:uint;
test += P;
trace(test);
}
}
}
Attach this class to a new flash document and run it, you'll get an 'Ambiguous reference to P' error.
Change the P setter access modifier to public and there isn't error anymore.
So my question is why setting the access modifier to protected or private cause this error ?
How can this make the reference ambiguous as it was not when it was public ?
When using P in the constructor, the compiler have only 2 choice : determine if it is the getter or the setter that is used. As it is an affectation, it is obviously the getter, but it could also be hesitating with the P setter function reference (as function can be referenced like that in actionscript) supposing it is able to imagine i would want to add a function to an uint. But in this case, why is it not hesitating when the access modifier is public ?
An other posibility is that namespace resolving is done before getter or setter resolving, so as access modifiers are considered as namespaces, it could not to know which namespace to use, but how to solve the problem in this case as there is no way to specify which access modifier to use.
Certainly in this case i could replace test += P by test += _p, but the error occurs also when i try P = 3 and in this case, i could want some additional code to be processed when i set P value.
Thank you for helping me.
Copy link to clipboard
Copied
Ok sorry there is a already a response there.
http://forums.adobe.com/message/79145#79145
Per Matt Chotin:
"It’s intentional right now that a getter/setter pair must have a matching visibility modifier. You can’t change whether a variable is visible to the compiler based on whether it’s being read or being written. While we understand the use-case (and debated it internally ourselves) this is the approach we’re taking right now."