[Laszlo-dev] For Review: Change change.YnPVbvuCF.txt Summary: Rewrite LzTimer to use setInterval/clearInterval instead of LzIdle

[Max Carlson]

Comments below:

Jim Grandy wrote:
> All great questions! I started writing up all the complexities last 
> night, but this is better.
> 
> On Jun 28, 2006, at 3:57 AM, P T Withington wrote:
> 
>> Cool!
>>
>> I am pretty sure that it is more efficient to write `x instanceof 
>> Object` than `typeof x == 'object'`
>>
> Thanks, I'll fix this.
>> This is a nit:  { d : d } is confusing.  { 'd': d } might be clearer, 
>> or better yet { delegate: d }?
>>
> And this. Not { 'delegate' : d } ? I also changed the closure to use 
> p.delegate, since I dimly remember bugs with capturing outer function 
> parameters. It's a bit clearer, as well.
>> Flash 8 includes setTimeout, which will make your code simpler (it's a 
>> one-shot).
>>
> Yeah, but this was for trunk, which has to support 6 and 7. I'll file a 
> bug that we add a variant using setTimeout... OK, LPP-2270.
>> I'm confused.  How can this work:  `this.timerList[d]` (where d is a 
>> delegate, hence an object?)
>>
> Hrm? It certainly does work. You can use any object as a key in 
> JavaScript, no?

My understanding is, the object will get coerced to a string since 
object keys must be strings. This only works if the object being used as 
a key has a toString() method that returns something unique per instance.

>> Do we need to maintain the complexity of multiple timers on a 
>> delegate, or is that a generality of the old system that was actually 
>> never used? Can we change to only allow a single timer per delegate?
> 
> I couldn't find a case where it was explicitly used, but I also couldn't 
> prove to myself that it wasn't inadvertently or surreptitiously used 
> somewhere. If we dropped this, it should be dropped in Legals.
> 
> But I'd be in favor of the change -- I'll even write the RFC proposing 
> it. There are some other improvements that could be made to the API.

I'm pretty sure we need this functionality.

>>    If we do have to support multiple timers on a delegate, maybe it 
>> would be better to store the timer id's on the delegate?
> 
> I thought of that too, and coded it up but then realized it wouldn't 
> work. The problem is that theoretically the caller to addTimer could 
> pass in any object with an execute() function, and then we'd lose our 
> bookkeeping and leak timers. This tends to be catastrophic since in that 
> case they don't just leak, they multiply exponentially.
 >
>> And if we do have to support this complexity, there ought to be a test 
>> for it.
>>
> Agreed. In my defense, I didn't think I could get very far without 
> asynchronous tests, and I don't know how to do that flavor in LzUnit.

We need to figure this out for testing media and data loading...

-- 
Regards,
Max Carlson
OpenLaszlo.org