[Laszlo-dev] setAttribute changes?
Sarah Allen
sarah at ultrasaurus.com
Mon Jan 19 06:50:28 PST 2009
sounds fabulous. Thanks for the explanation!
On Jan 19, 2009, at 6:33 AM, P T Withington wrote:
> My opinion is that there is never such a use case, hence, I want to
> remove the API change that was introduced in 4.0 (with no RFC). I
> believe it was a misguided optimization because:
>
> a) setAttribute has side-effects. Users expect an event when
> setAttribute is called, wether the value changes or not.
>
> b) if you have a custom setter, setAttribute can't even tell whether
> or not the value is a change or not
>
> c) if you are trying not to have the overhead of a function call,
> then the client of setAttribute should decide if calling is
> unnecessary and not call it.
>
> d) when we replace setAttribute with real setters, there can't be a
> 3rd optional argument.
>
> My change reverts setAttribute to its 3.x specification.
>
> On 2009-01-19, at 09:17EST, Sarah Allen wrote:
>
>> Can someone elaborate on the setAttribute changes? What's a use
>> case where the setter would not be called?
>>
>> Thanks,
>> Sarah
>>
>>
>> On Jan 18, 2009, at 1:32 PM, André Bargull wrote:
>>
>>> The changes for "setAttribute" are going to be an official &
>>> approved API-change, right? Even if it is bogus, maybe some people
>>> found it handy the way it was implemented, so we need to document
>>> these changes and create a release note!?
>>>
>>>
>>> On 1/18/2009 8:25 PM, P T Withington wrote:
>>>> Change 20090118-ptw-V by ptw at dueling-banjos.home on 2009-01-18
>>>> 13:28:54 EST
>>>> in /Users/ptw/OpenLaszlo/trunk
>>>> for http://svn.openlaszlo.org/openlaszlo/trunk
>>>>
>>>> Summary: Improve setAttribute and event sending
>>>>
>>>> Bugs Fixed:
>>>> LPP-7635 Ensure all memoizations use identity (===) not equality
>>>> (==) for their comparison (parital)
>>>> LPP-7452 setAttribute (actually: LzView.set_x) sometimes without
>>>> immediate effect
>>>>
>>>> Technical Reviewer: a.bargull at intensis.de (pending)
>>>> QA Reviewer: philip at pbrdev.com (pending)
>>>>
>>>> Details:
>>>>
>>>> setAttribute really cannot be memoized because it has side-effects
>>>> (the sending of an event). If is is called, the expectation is
>>>> that either the custom setter will be called (which should send an
>>>> event) or the default setter will send an event.
>>>>
>>>> LzEventable, JavascriptGenerator, CodeGenerator: Remove the
>>>> `ifchanged` option. This was only used (redundantly!) in
>>>> LzResizeReplicationManager. Per above, we can't memoize anyways.
>>>>
>>>> LzDefs: Remove stale comment
>>>>
>>>> LzView: Ensure x and y reflect the value setAttribute sets them
>>>> to, even if memoization causes the setter to be shortcut.
>>>>
>>>> LzEvent: Optimize `ready` to false when the event is already being
>>>> sent, which will avoid useless function calls. Remove redundant
>>>> `locked`, which is implied by `! ready`.
>>>>
>>>> LzResizeReplicationManager: Remove obsolete 3rd argument to
>>>> setAttribute.
>>>>
>>>> Tests:
>>>> smokecheck
>>>>
>>>> Files:
>>>> M WEB-INF/lps/lfc/core/LzEventable.lzs
>>>> M WEB-INF/lps/lfc/core/LzDefs.lzs
>>>> M WEB-INF/lps/lfc/views/LaszloView.lzs
>>>> M WEB-INF/lps/lfc/events/LaszloEvents.lzs
>>>> M WEB-INF/lps/lfc/data/LzResizeReplicationManager.lzs
>>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/
>>>> JavascriptGenerator.java
>>>> M WEB-INF/lps/server/src/org/openlaszlo/sc/CodeGenerator.java
>>>>
>>>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20090118-ptw-V.tar
>>>>
>>
>
More information about the Laszlo-dev
mailing list