setTimeout must return positive id

[tedbeer]

setTimeout must return positive id. Currently it starts from 0. Zero (false) id usually is used to distinguish initialized and not initialized values.
Example:

if( timer)
 clearTimeout(timer);

timer = setTimeout(function(){}, 1000);

[nic]

I don't think it's a problem. It's a feature.
Indeed I think Espruino simple don't catch this kind of exception (initialization fail) to return 0.
Well, will be necessary implement the exception support first, but for me it's fine starting at zero because:

float *TabNum;
TabNum = (float *) malloc (sizeof(float) * 3);
*(TabNum + 0)=42; //look, it's starting in the first place of memory!
*(TabNum + 1)=42;
*(TabNum + 2)=42;

It's starting in zero count! I think this is the motivation.

[nic]

These lines which created this behavior:

jswrap_io.c:231

JsVar *itemIndex = 0;
itemIndex = jsvNewFromInteger(jsvArrayPush(timerArrayPtr, timerPtr) - 1);
return itemIndex;

[afloyd]

I agree with @tedbeer . The intent of the microcontroller is to be able to code in a "familiar" syntax and pattern using JavaScript as the language. And in JavaScript intervals do not give zero as an id

[nic]

For comparison: NodeJS returns an object instead of a integer..

timer = setTimeout(function(){}, 1000);
typeof timer //return 'object'

timer

{ _idleTimeout: 1000,
  _idlePrev: null,
  _idleNext: null,
  _idleStart: 1380597475007,
  _onTimeout: [Function],
  _repeat: false }

[gfwilliams]

IMO ideally this would give an Object as a response - the integers can be confusing:

setTimeout(function(){}, 1000); // 0
clearTimeout(0); 
setTimeout(function(){}, 1000); // also 0

nic: thanks! internally Espruino is scarily similar so it might make sense for me to just rename the contents of the Timer object and return it just like node.js does!

But this is low priority IMO - on failure setTimeout will return undefined anyway, and I think this is totally a matter of taste. MDN docs don't seem to specify that IDs are always >0, and personally I like my arrays and numbers to start from 0.

[afloyd]

I definitely like having an object returned better, as it gives you more control/insight into the timer after creation. I guess I just thought Espruino was going for a mostly native JavaScript experience...

One issue going away from native behavior is if you were using some NPM modules or something along that nature, if they need/use setTimeout or any of the other native ECMAScript features that do not behave the same as ECMAScript, then they would have to be modified to work properly on Espruino

[gfwilliams]

Is returning an object not native? nic's post seems to suggest that node returns an object - and node.js compatibility is what we're going for.

[afloyd]

Sorry yea I was incorrect in my previous statement... After some quick research it's not even ECMAScript that "controls" the timers, it's the window (browser) object, and each one "could" behave differently. Most browsers I have noticed return a non-zero integer, but yes NodeJS returns an object. So if you did

var num=0, 
     timer = setInterval(function(){console.log(++num);}, 5000);
console.log(timer);

You would get (before the timoute is executed):

{ _idleTimeout: 10000,
  _idlePrev:
   { _idleNext: [Circular],
     _idlePrev: [Circular],
     msecs: 10000,
     ontimeout: [Function: listOnTimeout] },
  _idleNext:
   { _idleNext: [Circular],
     _idlePrev: [Circular],
     msecs: 10000,
     ontimeout: [Function: listOnTimeout] },
  _idleStart: 1380631615634,
  _onTimeout: [Function] }

After timeout execution console.log(timer) returns:

{ _idleTimeout: 10000,
  _idlePrev: null,
  _idleNext: null,
  _idleStart: 1380631615634,
  _onTimeout: [Function] }

You can pass clearTimeout the timer object, so I don't think a integer is necessary. Doing clearTimeout(timer);console.log(timer); shows the object is now:

{ _idleTimeout: -1,
  _idlePrev: null,
  _idleNext: null,
  _idleStart: 1380631951666,
  _onTimeout: null,
  ontimeout: null }

So I think the general behavior between the "native" browser implementation and NodeJS implementation is close enough that there would be no problems for code written for either browser style or NodeJS JavaScript implementations. The only chance I could see running into a problem is if you tried to use a code snippet where the if check relied on the value of the timer being an integer.

You can do an if(timer) check and it will still pass if the timer is an object as in NodeJS. However, the current implementation returning zero would not pass that scenario so I believe at least that part should be updated as initially requested by @tedbeer.

On the "flip side" since you're shooting for NodeJS compatability, if a NPM module expected to use one of the properties of a returned timer such as dynamically changing behavior by swapping out it's ontimeout property while it's running it would throw an exception...

[tedbeer]

What's the problem? You can use internally id starting 0. But give outside what javascript developers get used to.

id = setTimeout() // return internal_id + 1
clearTimeout(id) // internal_id = id - 1 and clear it

[shoork]

+1 with tedbeer...