[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