In the short-term, we still have runtimes with performance issues, so I
highly recommend calling setter methods when available. Especially in
Flash which imposes a serious tax on method calls, I avoid them wherever
possible. #2 sounds nifty, but till its implemented (by the compiler?),
I can't justify using slower syntax.
Personally, I don't think it should really matter so much in the docs
for the attribute if something has a setter or not -- only if it is
settable, read-only or final. (When I documented stuff for v2, I
believe that everything that was settable was doc'd as setter, since I
think we only had that category)
Sarah
P T Withington wrote:
> I disagree with this proposal (at least in the long term), for two
> reasons.
>
> 1) I thought our current stance was that you should _not_ call setter
> methods directly. That you should always use SetAttribute to set an
> attribute on an LZX class. Therefore rather than raising the
> distinction between attributes with setters and attributes without
> setters, I would seek to minimize it. If an attribute is meant to be
> read-only, you currently specify that by declaring it to have a null
> setter.
>
> 2) We are trying to move the language in the direction of ECMAScript
> v.4/Javascript 2.0. In those proposals, you are allowed to declare
> setter and getter methods that will be invoked by the member access
> syntax. When this is done, SetAttribute can be replaced by setting
> the attribute directly.
>
> Obviously 2 has a way to go, but I might as well outline my thoughts
> here. I'd like to propose that in place of the `setter` and `getter`
> properties of the `attribute` tag we create an `allocation`
> property. The allocation property has as possible values: `instance`
> (default), `class`, `each-subclass`, and `virtual`. The virtual
> allocation is used to create a slot that is implemented by getters
> and setters. E.g.:
>
> <attribute name="foo" allocation="virtual" />
> <attribute name="fooState" />
>
> <method name="get foo">
> return f(fooState);
> </method>
>
> <method name="set foo" arguments="newValue">
> fooState = g(newValue);
> </method>
>
> [No credit for this proposal, this is how Dylan does it. I think it
> is a clean way.]
>
> Furthermore, I'd like to clean up our event model at the same time.
> Currently, events are in the same domain as attributes. By
> convention they are named with the prefix 'on'. This leads to
> confusion. Does the attribute `once` refer to once, or is it an
> event sent by the ce attribute? Currently events occur
> automatically, _if_ you obey the protocol of always using
> `setAttribute` to set your attributes. This mechanism is prone to
> failure (if an attribute is set directly), and has overhead
> implications (for attributes that no one is listening for). As part
> of the new event/handler tags, I'd like to propose that _only_
> declared events are ever sent. This will reduce overhead, allow
> checking for trying to handle a non-existent event, and permit the
> compiler to implement default event sending using Javascript
> setters. We can keep the convention of calling events 'on'+..., but
> they will be managed in a domain separate from attributes, so you
> will know that the attribute 'once' is what it is, whereas the event
> 'once' is for the 'ce' attribute. So, carrying on with the example
> above, if the `foo` attribute sends events, you would say:
>
> <event name='onfoo'/>
>
> and in the setter:
>
> <method name="set foo" arguments="newValue">
> fooState = g(newValue);
> events.onfoo.send(newValue);
> </method>
>
> [Sorry for doing a core-dump on your proposal, but these are a couple
> of issues that have been rattling around in my head for a while. I
> will try to make a more formal proposal soon.]
>
> On 2006-02-17, at 19:20 EST, Antun Karlovac wrote:
>
>> When we originally designed the reference, we broke attributes down
>> into 5 categories:
>>
>> 1. Attributes with setter (setter)
>> 2. Attributes without setter (defaultsetter)
>> 3. Event handler attributes (eventhandler)
>> 4. Final attributes (final)
>> 5. Read only attributes (readonly)
>>
>> We never actually used the defaultsetter attribute category while
>> documenting the components. Indeed, there was a bug in the
>> rng2xml.py parser that prevented it from even being picked up (I
>> just discovered: LPP-1615).
>>
>> The defaultsetter category *is* useful. Consider this simplified
>> example of alert:
>>
>> <class name="alert" extends="modaldialog">
>> <attribute name="text" type="html" value="" />
>> <text name="label" x="5" y="5" text="${parent.text}" />
>> <button....>
>> </class>
>>
>> In your app you might instantiate it at the canvas level once, and
>> use it like so:
>>
>> <canvas>
>> <alert name="myAlert" />
>>
>> <button>Open alert with message
>> <method event="onclick">
>> myAlert.open();
>> myAlert.setAttribute("text","You sure you want to do
>> that?");
>> </method>
>> </button>
>> </canvas>
>>
>> In this case, "text" *is* a settable attribute of alert, but *does
>> not* have a setter (we haven't defined a setText() method).
>>
>> Originally there was some resistance to using the defaultsetter
>> category because, it was argued, our components will never want for
>> setter methods. The problem with adding setter methods for every
>> attribute is that they add download size (they're JavaScript, after
>> all). Therefore we shouldn't create unnecessary setter methods for
>> all attributes that are settable.
>>
>> Enter the defaultsetter attribute - it lets the developer know that
>> they are allowed to set this attribute at run-time, but that they
>> need to use setAttribute("text",...) instead of setText(...).
>>
>> In the above example, you would document it as follows:
>> <!--- The text to be displayed in the alert box
>> @keywords defaultsetter -->
>> <attribute name="text" type="html" value="" />
>>
>> The defaultsetter category has always been documented here:
>> http://www.openlaszlo.org/lps-latest/docs/reference/index.html?info-
>> attributes.html#defaultsetter
>> or... http://tinyurl.com/arvah
>>
>> I have a fix for LPP-1615, and I plan to declare the first
>> defaultsetter attribute in a pending change for basecombobox. We
>> should use it where appropriate.
>>
>> -Antun
>> _______________________________________________
>> Laszlo-dev mailing list
>> [email protected]
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
