Forums » General

PropertySetter vs. MethodInvoker

(3 posts)
  • Started 6 months ago by smebberson
  • Latest reply from Stiggler
  1. Hey guys, I've recently stumbled across the PropertySetter tag and have found it to be the missing link in using proper setter/getter properties in Managers. My EventMap and Manager used to look like this:


    <EventHandlers type="{PreferencesEvent.BREAK_LENGTH}" debug="false">
    <MethodInvoker generator="{ApplicationManager}" method="setBreakLength" arguments="{event.value}" />
    </EventHandlers>

    ...

    private var _breakLength : int = 0;

    [Bindable(event="breakLengthChanged")]
    public function get breakLength () : int
    {
    return _breakLength;
    }

    public function setBreakLength (value : int) : void
    {
    breakLength = value;
    }

    But now they look like this:


    <EventHandlers type="{PreferencesEvent.BREAK_LENGTH}" debug="false">
    <PropertySetter generator="{ApplicationManager}" targetKey="breakLength" source="{event.value}" />
    </EventHandlers>

    ...

    /* PROPERTY: breakLength */
    private var _breakLength : int = 0;

    [Bindable(event="breakLengthChanged")]
    public function get breakLength () : int
    {
    return _breakLength;
    }

    public function set breakLength (value : int) : void
    {
    _breakLength = value;
    dispatchEvent(new Event('breakLengthChanged'));
    }

    The latter feels much nicer to me, using proper getter/setter properties in my Manager.

    Is there any downside to this or reason I shouldn't be programming it this way?

    Posted 6 months ago #
  2. I'm wearing the same optics as you are and also find myself coding PropertySetters in favor of MethodInvokers for that stuff, and I'm thinking that some of the "confusion" about what is the preferred way to do what you try to do, might originate among hardnock Java developers has been a resistance to using Gettes/Setters (Properties) in favor of the traditional get*/set* set of methods.

    However, it all depends on if it truly IS a welldesigned property which might not be the case all the time. I see many people implement incorrect functional in properties... by incorrect I mean that properties are supposed to be simple implementations and not do too much logic before it should refactored into a method, and also a getter MUST always return the same value at every call if the object has not changed state in any other way. I remember this discussion from the .NET forums some years ago when they released the DateTime.Now property... which in essence would never return the same value, despite that the DateTime had not been manipulated in any other way in between calls (you can argue that the continuum of time is a change of state in the DateTime class, however to my knowledge it came to be known as a nice example of a property gone wrong...

    Just my 5 cents... :-)

    Posted 6 months ago #
  3. Stiggler
    Member

    I've also been thinking about this...
    PropertySetter is a relative newcomer. Prior to it being added, MethodInvoker was the only option, probably explaining why many example managers are structured with a setter method instead of a proper getter/setter property. I'd love to hear some more discussion on the subject if it's any more complicated than that, though.

    Posted 6 months ago #

RSS feed for this topic

Reply

You must log in to post.