You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2016/11/22 05:48:46 UTC

[Bindable] and private setters (was Re: [Falcon])

After some investigation, it appears that for classes with [Bindable],
with MXMLC you could get away with having a public getter and private
setter.  But that is because the MXMLC compiler converts the setter to a
public setter, defeating the whole point of making a private setter.

So, I'd like to get ideas on what Falcon should do.  Currently Falcon
reports an error like MXMLC does when a class isn't [Bindable] but has a
public getter and private setter.  Should Falcon also convert the setter
to public like MXMLC does so existing code will continue to run even
though there is a chance you have a bug in your code where you are
accidentally setting the property from outside the class?

Seems like it is a bug that MXMLC converts the setter to public and so
Falcon should not replicate that bug.

Thoughts?
-Alex

On 11/21/16, 12:22 AM, "Harbs" <ha...@gmail.com> wrote:

>I changed it to this.regular = font and I’m still getting the same error.
>
>On Nov 21, 2016, at 10:18 AM, Harbs <ha...@gmail.com> wrote:
>
>> Huh.
>> 
>> I just did a code review, and it looks like “this” was removed from the
>>FlexJS code a number of months ago. Not sure why…
>> 
>> On Nov 21, 2016, at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
>> 
>>> Please post a small test case I can compile with MXMLC.
>>> 
>>> -Alex
>>> 
>>> On 11/20/16, 11:37 PM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>>> Yes. This code is about 4 or 5 years old and I’ve had no errors to
>>>>date.
>>>> 
>>>> On Nov 21, 2016, at 9:35 AM, Alex Harui <ah...@adobe.com> wrote:
>>>> 
>>>>> Are you sure MXMLC compiles your code without error?  MXMLC reported
>>>>>the
>>>>> "read-only" error for me.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>> On 11/20/16, 10:44 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>> 
>>>>>> The latest Falcon breaks valid existing code patterns.
>>>>>> 
>>>>>> I know there was a recent discussion on related, but I can’t find it
>>>>>> right now.
>>>>>> 
>>>>>> I have some code which I migrated from a Flash app:
>>>>>> 
>>>>>> 		private var _regular:FontVO;
>>>>>> 		public function get regular():FontVO
>>>>>> 		{
>>>>>> 			return _regular;
>>>>>> 		}
>>>>>> 		private function set regular(value:FontVO):void
>>>>>> 		{
>>>>>> 			_regular = value;
>>>>>> 		}
>>>>>> 
>>>>>> 
>>>>>> Somewhere else in the same class I have the following:
>>>>>> 
>>>>>> 			if(style.toLowerCase() == "regular" || style.toLowerCase() ==
>>>>>> "normal"){
>>>>>> 				regular = font;
>>>>>> 			}
>>>>>> 
>>>>>> This code compiled and worked correctly in Flash as well as in
>>>>>>Falcon
>>>>>> until today. I’m now getting an error:
>>>>>> Property regular is read-only.
>>>>>> 
>>>>>> 				regular = font;
>>>>>> 				^
>>>>>> 
>>>>>> This code is in the same class, but the compiler is not recognizing
>>>>>>the
>>>>>> private setter.
>>>>>> 
>>>>>> Thanks,
>>>>>> Harbs
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>


Re: [Bindable] and private setters (was Re: [Falcon])

Posted by Josh Tynjala <jo...@gmail.com>.
Perhaps Falcon should have a specific compiler error or warning that says
that setters must be public when using [Bindable]. I assume that the
current error is kind of generic, so something more specific would help
make it clear what's wrong and how to fix it.

- Josh

On Mon, Nov 21, 2016 at 9:48 PM, Alex Harui <ah...@adobe.com> wrote:

> After some investigation, it appears that for classes with [Bindable],
> with MXMLC you could get away with having a public getter and private
> setter.  But that is because the MXMLC compiler converts the setter to a
> public setter, defeating the whole point of making a private setter.
>
> So, I'd like to get ideas on what Falcon should do.  Currently Falcon
> reports an error like MXMLC does when a class isn't [Bindable] but has a
> public getter and private setter.  Should Falcon also convert the setter
> to public like MXMLC does so existing code will continue to run even
> though there is a chance you have a bug in your code where you are
> accidentally setting the property from outside the class?
>
> Seems like it is a bug that MXMLC converts the setter to public and so
> Falcon should not replicate that bug.
>
> Thoughts?
> -Alex
>
> On 11/21/16, 12:22 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >I changed it to this.regular = font and I’m still getting the same error.
> >
> >On Nov 21, 2016, at 10:18 AM, Harbs <ha...@gmail.com> wrote:
> >
> >> Huh.
> >>
> >> I just did a code review, and it looks like “this” was removed from the
> >>FlexJS code a number of months ago. Not sure why…
> >>
> >> On Nov 21, 2016, at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>> Please post a small test case I can compile with MXMLC.
> >>>
> >>> -Alex
> >>>
> >>> On 11/20/16, 11:37 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>
> >>>> Yes. This code is about 4 or 5 years old and I’ve had no errors to
> >>>>date.
> >>>>
> >>>> On Nov 21, 2016, at 9:35 AM, Alex Harui <ah...@adobe.com> wrote:
> >>>>
> >>>>> Are you sure MXMLC compiles your code without error?  MXMLC reported
> >>>>>the
> >>>>> "read-only" error for me.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 11/20/16, 10:44 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>
> >>>>>> The latest Falcon breaks valid existing code patterns.
> >>>>>>
> >>>>>> I know there was a recent discussion on related, but I can’t find it
> >>>>>> right now.
> >>>>>>
> >>>>>> I have some code which I migrated from a Flash app:
> >>>>>>
> >>>>>>          private var _regular:FontVO;
> >>>>>>          public function get regular():FontVO
> >>>>>>          {
> >>>>>>                  return _regular;
> >>>>>>          }
> >>>>>>          private function set regular(value:FontVO):void
> >>>>>>          {
> >>>>>>                  _regular = value;
> >>>>>>          }
> >>>>>>
> >>>>>>
> >>>>>> Somewhere else in the same class I have the following:
> >>>>>>
> >>>>>>                  if(style.toLowerCase() == "regular" ||
> style.toLowerCase() ==
> >>>>>> "normal"){
> >>>>>>                          regular = font;
> >>>>>>                  }
> >>>>>>
> >>>>>> This code compiled and worked correctly in Flash as well as in
> >>>>>>Falcon
> >>>>>> until today. I’m now getting an error:
> >>>>>> Property regular is read-only.
> >>>>>>
> >>>>>>                          regular = font;
> >>>>>>                          ^
> >>>>>>
> >>>>>> This code is in the same class, but the compiler is not recognizing
> >>>>>>the
> >>>>>> private setter.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Harbs
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>

RE: [Bindable] and private setters (was Re: [Falcon])

Posted by Kessler CTR Mark J <ma...@usmc.mil>.
+1 for leaving the setter private.

-Mark

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Tuesday, November 22, 2016 1:01 PM
To: dev@flex.apache.org
Subject: Re: [Bindable] and private setters (was Re: [Falcon])



On 11/22/16, 9:26 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>If they make the getter public and the setter private, it's probably on
>purpose. If the compiler then forces the setter to be public for
>[Bindable], it should at least tell them that something probably
>unexpected
>is happening. I think a warning makes sense.

I don't think that [Bindable] has to force the setter to be public.

IMO, the right answer is to leave the setter as private and you'll get the
same errors as if you didn't use [Bindable] which is an error about
read-only if you don't use the private:: prefix.  That isn't completely
obvious, but at least is consistent.

Thoughts?
-Alex



Re: [Bindable] and private setters (was Re: [Falcon])

Posted by Josh Tynjala <jo...@gmail.com>.
That works for me. I wonder if we can show a different error if there's a
non-public setter. I remember being confused for a bit the first time I saw
that error about the property being read-only.

- Josh

On Tue, Nov 22, 2016 at 10:01 AM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 11/22/16, 9:26 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>
> >If they make the getter public and the setter private, it's probably on
> >purpose. If the compiler then forces the setter to be public for
> >[Bindable], it should at least tell them that something probably
> >unexpected
> >is happening. I think a warning makes sense.
>
> I don't think that [Bindable] has to force the setter to be public.
>
> IMO, the right answer is to leave the setter as private and you'll get the
> same errors as if you didn't use [Bindable] which is an error about
> read-only if you don't use the private:: prefix.  That isn't completely
> obvious, but at least is consistent.
>
> Thoughts?
> -Alex
>
>
>

Re: [Bindable] and private setters (was Re: [Falcon])

Posted by Alex Harui <ah...@adobe.com>.

On 11/22/16, 9:26 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>If they make the getter public and the setter private, it's probably on
>purpose. If the compiler then forces the setter to be public for
>[Bindable], it should at least tell them that something probably
>unexpected
>is happening. I think a warning makes sense.

I don't think that [Bindable] has to force the setter to be public.

IMO, the right answer is to leave the setter as private and you'll get the
same errors as if you didn't use [Bindable] which is an error about
read-only if you don't use the private:: prefix.  That isn't completely
obvious, but at least is consistent.

Thoughts?
-Alex



Re: [Bindable] and private setters (was Re: [Falcon])

Posted by Josh Tynjala <jo...@gmail.com>.
If they make the getter public and the setter private, it's probably on
purpose. If the compiler then forces the setter to be public for
[Bindable], it should at least tell them that something probably unexpected
is happening. I think a warning makes sense.

[Bindable(eventName)] is definitely the right choice as a best practice,
but many developers are lazy and just slap on [Bindable] and let the
compiler take care of the events for them.

- Josh

On Tue, Nov 22, 2016 at 9:08 AM, Alex Harui <ah...@adobe.com> wrote:

> I think it should be possible to generate the right code for [Bindable] so
> that the setter remains private.  But then when the code tries to access
> the setter without the "private::" namespace you will get a "read-only"
> error.
>
> Regarding Josh's feedback, I'm not sure we should detect a mismatch
> between getter and setter access and report an error. Or should we report
> a warning?  It is valid code since you can access the private setter via
> "private::setterName"?
>
> BTW, why do folks use getter/setters and [Bindable]?  The compiler
> actually renames your getter and setter and generates new getters and
> setters that wrap the ones you wrote, so now there are two function calls
> to get the variable.  IOW, if your code looks like:
>
>   private var _foo:String;
>   public function get foo():String
>   {
>       return _foo;
>   }
>   public function set foo(value:String):void
>   {
>       _foo = value;
>   }
>
>
> Then when [Bindable] is used, the compiler generates:
>
>   public function get _somerandomnumber_foo():String
>   {
>       return _foo;
>   }
>   public function set _somerandomnumber_foo(value:String):void
>   {
>       _foo = value;
>   }
>   public function get foo():String
>   {
>       return _somerandomnumber_foo();
>   }
>   public function set foo(value:String):void
>   {
>      _somerandomnumber_foo = value;
>   }
>
>
> IMO, it is just as easy to write a custom setter and use
> [Bindable(eventName)]:
>
>   private var _foo:String;
>   [Bindable("fooChanged")]
>   public function get foo():String
>   {
>       return _foo;
>   }
>   public function set foo(value:String):void
>   {
>       _foo = value;
>       dispatchEvent(new Event("fooChanged"));
>   }
>
> My 2 cents,
> -Alex
>
>
>
> On 11/22/16, 7:55 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >Agreed. It should not do automatic conversions.
> >
> >Now that you mention it, I’ve been getting Bindable warnings on those
> >classes for years. Everything worked, so I ignored it, but I would not be
> >surprised if the warnings were related to this issue.
> >
> >Thanks for looking into this.
> >
> >Harbs
> >
> >On Nov 22, 2016, at 7:48 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> After some investigation, it appears that for classes with [Bindable],
> >> with MXMLC you could get away with having a public getter and private
> >> setter.  But that is because the MXMLC compiler converts the setter to a
> >> public setter, defeating the whole point of making a private setter.
> >>
> >> So, I'd like to get ideas on what Falcon should do.  Currently Falcon
> >> reports an error like MXMLC does when a class isn't [Bindable] but has a
> >> public getter and private setter.  Should Falcon also convert the setter
> >> to public like MXMLC does so existing code will continue to run even
> >> though there is a chance you have a bug in your code where you are
> >> accidentally setting the property from outside the class?
> >>
> >> Seems like it is a bug that MXMLC converts the setter to public and so
> >> Falcon should not replicate that bug.
> >>
> >> Thoughts?
> >> -Alex
> >>
> >> On 11/21/16, 12:22 AM, "Harbs" <ha...@gmail.com> wrote:
> >>
> >>> I changed it to this.regular = font and I’m still getting the same
> >>>error.
> >>>
> >>> On Nov 21, 2016, at 10:18 AM, Harbs <ha...@gmail.com> wrote:
> >>>
> >>>> Huh.
> >>>>
> >>>> I just did a code review, and it looks like “this” was removed from
> >>>>the
> >>>> FlexJS code a number of months ago. Not sure why…
> >>>>
> >>>> On Nov 21, 2016, at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
> >>>>
> >>>>> Please post a small test case I can compile with MXMLC.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 11/20/16, 11:37 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>
> >>>>>> Yes. This code is about 4 or 5 years old and I’ve had no errors to
> >>>>>> date.
> >>>>>>
> >>>>>> On Nov 21, 2016, at 9:35 AM, Alex Harui <ah...@adobe.com> wrote:
> >>>>>>
> >>>>>>> Are you sure MXMLC compiles your code without error?  MXMLC
> >>>>>>>reported
> >>>>>>> the
> >>>>>>> "read-only" error for me.
> >>>>>>>
> >>>>>>> -Alex
> >>>>>>>
> >>>>>>> On 11/20/16, 10:44 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> The latest Falcon breaks valid existing code patterns.
> >>>>>>>>
> >>>>>>>> I know there was a recent discussion on related, but I can’t find
> >>>>>>>>it
> >>>>>>>> right now.
> >>>>>>>>
> >>>>>>>> I have some code which I migrated from a Flash app:
> >>>>>>>>
> >>>>>>>>                private var _regular:FontVO;
> >>>>>>>>                public function get regular():FontVO
> >>>>>>>>                {
> >>>>>>>>                        return _regular;
> >>>>>>>>                }
> >>>>>>>>                private function set regular(value:FontVO):void
> >>>>>>>>                {
> >>>>>>>>                        _regular = value;
> >>>>>>>>                }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Somewhere else in the same class I have the following:
> >>>>>>>>
> >>>>>>>>                        if(style.toLowerCase() == "regular" ||
> style.toLowerCase() ==
> >>>>>>>> "normal"){
> >>>>>>>>                                regular = font;
> >>>>>>>>                        }
> >>>>>>>>
> >>>>>>>> This code compiled and worked correctly in Flash as well as in
> >>>>>>>> Falcon
> >>>>>>>> until today. I’m now getting an error:
> >>>>>>>> Property regular is read-only.
> >>>>>>>>
> >>>>>>>>                                regular = font;
> >>>>>>>>                                ^
> >>>>>>>>
> >>>>>>>> This code is in the same class, but the compiler is not
> >>>>>>>>recognizing
> >>>>>>>> the
> >>>>>>>> private setter.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Harbs
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>

Re: [Bindable] and private setters (was Re: [Falcon])

Posted by Alex Harui <ah...@adobe.com>.
I think it should be possible to generate the right code for [Bindable] so
that the setter remains private.  But then when the code tries to access
the setter without the "private::" namespace you will get a "read-only"
error.

Regarding Josh's feedback, I'm not sure we should detect a mismatch
between getter and setter access and report an error. Or should we report
a warning?  It is valid code since you can access the private setter via
"private::setterName"?

BTW, why do folks use getter/setters and [Bindable]?  The compiler
actually renames your getter and setter and generates new getters and
setters that wrap the ones you wrote, so now there are two function calls
to get the variable.  IOW, if your code looks like:

  private var _foo:String;
  public function get foo():String
  {
      return _foo;
  }
  public function set foo(value:String):void
  {
      _foo = value;
  }


Then when [Bindable] is used, the compiler generates:

  public function get _somerandomnumber_foo():String
  {
      return _foo;
  }
  public function set _somerandomnumber_foo(value:String):void
  {
      _foo = value;
  }
  public function get foo():String
  {
      return _somerandomnumber_foo();
  }
  public function set foo(value:String):void
  {
     _somerandomnumber_foo = value;
  }


IMO, it is just as easy to write a custom setter and use
[Bindable(eventName)]:

  private var _foo:String;
  [Bindable("fooChanged")]
  public function get foo():String
  {
      return _foo;
  }
  public function set foo(value:String):void
  {
      _foo = value;
      dispatchEvent(new Event("fooChanged"));
  }

My 2 cents,
-Alex



On 11/22/16, 7:55 AM, "Harbs" <ha...@gmail.com> wrote:

>Agreed. It should not do automatic conversions.
>
>Now that you mention it, I’ve been getting Bindable warnings on those
>classes for years. Everything worked, so I ignored it, but I would not be
>surprised if the warnings were related to this issue.
>
>Thanks for looking into this.
>
>Harbs
>
>On Nov 22, 2016, at 7:48 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> After some investigation, it appears that for classes with [Bindable],
>> with MXMLC you could get away with having a public getter and private
>> setter.  But that is because the MXMLC compiler converts the setter to a
>> public setter, defeating the whole point of making a private setter.
>> 
>> So, I'd like to get ideas on what Falcon should do.  Currently Falcon
>> reports an error like MXMLC does when a class isn't [Bindable] but has a
>> public getter and private setter.  Should Falcon also convert the setter
>> to public like MXMLC does so existing code will continue to run even
>> though there is a chance you have a bug in your code where you are
>> accidentally setting the property from outside the class?
>> 
>> Seems like it is a bug that MXMLC converts the setter to public and so
>> Falcon should not replicate that bug.
>> 
>> Thoughts?
>> -Alex
>> 
>> On 11/21/16, 12:22 AM, "Harbs" <ha...@gmail.com> wrote:
>> 
>>> I changed it to this.regular = font and I’m still getting the same
>>>error.
>>> 
>>> On Nov 21, 2016, at 10:18 AM, Harbs <ha...@gmail.com> wrote:
>>> 
>>>> Huh.
>>>> 
>>>> I just did a code review, and it looks like “this” was removed from
>>>>the
>>>> FlexJS code a number of months ago. Not sure why…
>>>> 
>>>> On Nov 21, 2016, at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
>>>> 
>>>>> Please post a small test case I can compile with MXMLC.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>> On 11/20/16, 11:37 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>> 
>>>>>> Yes. This code is about 4 or 5 years old and I’ve had no errors to
>>>>>> date.
>>>>>> 
>>>>>> On Nov 21, 2016, at 9:35 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>>> 
>>>>>>> Are you sure MXMLC compiles your code without error?  MXMLC
>>>>>>>reported
>>>>>>> the
>>>>>>> "read-only" error for me.
>>>>>>> 
>>>>>>> -Alex
>>>>>>> 
>>>>>>> On 11/20/16, 10:44 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> The latest Falcon breaks valid existing code patterns.
>>>>>>>> 
>>>>>>>> I know there was a recent discussion on related, but I can’t find
>>>>>>>>it
>>>>>>>> right now.
>>>>>>>> 
>>>>>>>> I have some code which I migrated from a Flash app:
>>>>>>>> 
>>>>>>>> 		private var _regular:FontVO;
>>>>>>>> 		public function get regular():FontVO
>>>>>>>> 		{
>>>>>>>> 			return _regular;
>>>>>>>> 		}
>>>>>>>> 		private function set regular(value:FontVO):void
>>>>>>>> 		{
>>>>>>>> 			_regular = value;
>>>>>>>> 		}
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Somewhere else in the same class I have the following:
>>>>>>>> 
>>>>>>>> 			if(style.toLowerCase() == "regular" || style.toLowerCase() ==
>>>>>>>> "normal"){
>>>>>>>> 				regular = font;
>>>>>>>> 			}
>>>>>>>> 
>>>>>>>> This code compiled and worked correctly in Flash as well as in
>>>>>>>> Falcon
>>>>>>>> until today. I’m now getting an error:
>>>>>>>> Property regular is read-only.
>>>>>>>> 
>>>>>>>> 				regular = font;
>>>>>>>> 				^
>>>>>>>> 
>>>>>>>> This code is in the same class, but the compiler is not
>>>>>>>>recognizing
>>>>>>>> the
>>>>>>>> private setter.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Harbs
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>


Re: [Bindable] and private setters (was Re: [Falcon])

Posted by Harbs <ha...@gmail.com>.
Agreed. It should not do automatic conversions.

Now that you mention it, I’ve been getting Bindable warnings on those classes for years. Everything worked, so I ignored it, but I would not be surprised if the warnings were related to this issue.

Thanks for looking into this.

Harbs

On Nov 22, 2016, at 7:48 AM, Alex Harui <ah...@adobe.com> wrote:

> After some investigation, it appears that for classes with [Bindable],
> with MXMLC you could get away with having a public getter and private
> setter.  But that is because the MXMLC compiler converts the setter to a
> public setter, defeating the whole point of making a private setter.
> 
> So, I'd like to get ideas on what Falcon should do.  Currently Falcon
> reports an error like MXMLC does when a class isn't [Bindable] but has a
> public getter and private setter.  Should Falcon also convert the setter
> to public like MXMLC does so existing code will continue to run even
> though there is a chance you have a bug in your code where you are
> accidentally setting the property from outside the class?
> 
> Seems like it is a bug that MXMLC converts the setter to public and so
> Falcon should not replicate that bug.
> 
> Thoughts?
> -Alex
> 
> On 11/21/16, 12:22 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> I changed it to this.regular = font and I’m still getting the same error.
>> 
>> On Nov 21, 2016, at 10:18 AM, Harbs <ha...@gmail.com> wrote:
>> 
>>> Huh.
>>> 
>>> I just did a code review, and it looks like “this” was removed from the
>>> FlexJS code a number of months ago. Not sure why…
>>> 
>>> On Nov 21, 2016, at 9:41 AM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>>> Please post a small test case I can compile with MXMLC.
>>>> 
>>>> -Alex
>>>> 
>>>> On 11/20/16, 11:37 PM, "Harbs" <ha...@gmail.com> wrote:
>>>> 
>>>>> Yes. This code is about 4 or 5 years old and I’ve had no errors to
>>>>> date.
>>>>> 
>>>>> On Nov 21, 2016, at 9:35 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>>> Are you sure MXMLC compiles your code without error?  MXMLC reported
>>>>>> the
>>>>>> "read-only" error for me.
>>>>>> 
>>>>>> -Alex
>>>>>> 
>>>>>> On 11/20/16, 10:44 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>> 
>>>>>>> The latest Falcon breaks valid existing code patterns.
>>>>>>> 
>>>>>>> I know there was a recent discussion on related, but I can’t find it
>>>>>>> right now.
>>>>>>> 
>>>>>>> I have some code which I migrated from a Flash app:
>>>>>>> 
>>>>>>> 		private var _regular:FontVO;
>>>>>>> 		public function get regular():FontVO
>>>>>>> 		{
>>>>>>> 			return _regular;
>>>>>>> 		}
>>>>>>> 		private function set regular(value:FontVO):void
>>>>>>> 		{
>>>>>>> 			_regular = value;
>>>>>>> 		}
>>>>>>> 
>>>>>>> 
>>>>>>> Somewhere else in the same class I have the following:
>>>>>>> 
>>>>>>> 			if(style.toLowerCase() == "regular" || style.toLowerCase() ==
>>>>>>> "normal"){
>>>>>>> 				regular = font;
>>>>>>> 			}
>>>>>>> 
>>>>>>> This code compiled and worked correctly in Flash as well as in
>>>>>>> Falcon
>>>>>>> until today. I’m now getting an error:
>>>>>>> Property regular is read-only.
>>>>>>> 
>>>>>>> 				regular = font;
>>>>>>> 				^
>>>>>>> 
>>>>>>> This code is in the same class, but the compiler is not recognizing
>>>>>>> the
>>>>>>> private setter.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Harbs
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>