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 <aha...@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" <harbs.li...@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 <aha...@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" <harbs.li...@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 <harbs.li...@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 <aha...@adobe.com> wrote:
> >>>>
> >>>>> Please post a small test case I can compile with MXMLC.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>> On 11/20/16, 11:37 PM, "Harbs" <harbs.li...@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 <aha...@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" <harbs.li...@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
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>

Reply via email to