[
https://issues.apache.org/jira/browse/FLEX-33182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443373#comment-13443373
]
Michael Labriola commented on FLEX-33182:
-----------------------------------------
Whenever you have your own getter and setter and use the Bindable tag without
specifying an event, the compiler renames your setter and creates a new one.
The new setter checks if the variable has changed and then calls your setter.
Its why it is wasteful to use [Bindable] with setters and not dispatch your own
event.
That said, there are two things here. First, its really bad to override the
setter that you happen to know exists only because of the Bindable tag. Talk
about needing to know too much about the internal workings of the compiler and
the class to extend it. Just using a getter/setter to begin with makes it so
much clearer and so much less likely not to blow up.
Clearly, after that, the compiler could be smarter in its approach, but
basically, I am guessing the combo of the bindable to originally generate the
setter combined with the existence of an override setter is causing it to get
caught in both passes taken to make binding work. Basically, the code was
genned for the property of the base class and it is regenerating more code for
the subclass.... so, basically, compiler issue yet... bad practice, yes.
> override public in subclass results in public write only property. public
> override works as expected
> ----------------------------------------------------------------------------------------------------
>
> Key: FLEX-33182
> URL: https://issues.apache.org/jira/browse/FLEX-33182
> Project: Apache Flex
> Issue Type: Bug
> Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: Flash Builder 4.6
> Reporter: Michael Grove
> Attachments: test.zip
>
>
> I'll upload a zip of classes and test cases for flexunit that demonstrate
> this problem. Here's the gist:
> We’ve found that the list of accessors is different if a derived class
> overrides a getter/setter with “public override” vs. “override public”.
> “override public” introduces an additional write only public property as
> shown in both describeType output and in Flash Builder.
> Here are some simple classes that demonstrate the problem, text continued
> below.
> package publicoverridevsoverridepublic
> {
> [Bindable]
> public class BaseClass
> {
> public var var1:String;
> public var var2:String;
> }
> }
> package publicoverridevsoverridepublic
> {
> [Bindable]
> public class SubClassOverridePublic extends BaseClass
> {
> override public function set var1(value:String):void
> {
> super.var1 = value;
> }
> override public function get var1():String
> {
> return super.var1;
> }
> }
> }
> package publicoverridevsoverridepublic
> {
> [Bindable]
> public class SubClassPublicOverride extends BaseClass
> {
> public override function set var1(value:String):void
> {
> super.var1 = value;
> }
> public override function get var1():String
> {
> return super.var1;
> }
> }
> }
> The attributes of SubClassPublicOverride in Flash Builder include a
> _3612138var1 property. It’s a private property that according to Flash
> Builder is write only (only includes a setter). I’m not sure what the
> purpose of this property is, or more generally any of the private properties
> I’ve seen in Flash Builder with numeric prefixes like this. And I’m not sure
> why it is believed only to have a setter. But as it is private, it is not
> included in the results from describeType().
> The attributes of SubClassOverridePublic in Flash Builder have the same
> _3612138var1 property but this time it is public and write only.
> I've never heard of any language treating "public override" and "override
> public" as semantically different and assume this must be a bug.
> Note that some Flex formatters out there are preconfigured to favor “override
> public” to “public override” (that’s actually what broke us – formatting the
> file). If you’re not using describeType you probably don’t care. But it’d
> be interesting to know what else might be different between “override public”
> and “public override”.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
