[9:56]<drbobb> hmm [9:56]<drbobb> http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Array:forEach#Description [9:57]<drbobb> callback (..) is not invoked for indexes which have been deleted or which have never been assigned values. [9:57]<drbobb> this seems to be not true in rhino [10:01]<drbobb> var a = (new Array(2)); a.forEach( function (e, i, a) { a[i] = i; } ); a.toSource(); [10:01]<zumbrunn> what about the implementation in the helmalib? [10:01]<drbobb> returns: [0, 1] [10:02]<zumbrunn> that probably just enumerates whatever is "enumerable", right? [10:02]<drbobb> 1 in (new Array(2)); [10:02]<drbobb> returns false (of course) [10:03]<drbobb> don't know about the helmalib, haven't looked it up yet [10:04]<drbobb> but rhino 1.6R7 does implement Array.forEach, except that it doesn't follow that description [10:05]<zumbrunn> what about the version of Array.prototype.forEach that is listed under "Compatibility"? [10:05]<drbobb> (i stumbled upon that when checking whether forEach visits array elements in order, the description doesn't say whether it must) [10:06]<drbobb> well that version does seem to follow the description [10:06]<drbobb> because of the conditional if (i in this) [10:10]<drbobb> where is an Array.prototype.forEach defined in helma? i can't find it [10:11]<drbobb> not in modules/core [10:12]<zumbrunn> I thought there still was one in core/Array.js, but there isn't [10:12]<zumbrunn> there is one in core/HopObject.js though [10:12]<zumbrunn> https://dev.helma.org/trac/helma/browser/apps/modules/trunk/core/HopObject.js [10:13]<drbobb> ok, but that won't apply to an arbitrary array [10:13]<zumbrunn> nope [10:16]<drbobb> spidermonkey does follow the doc, unlike rhino [10:16]<drbobb> the result is [undefined, undefined, ] [10:17]<drbobb> heh, another bug report in the works [10:17]<zumbrunn> :-) [10:31]<drbobb> ..done [15:14]<drbobb> ughh [15:14]<drbobb> js> [ !![], []==true ]; [15:15]<drbobb> true,false [15:18]<drbobb> well but this does agree with the spec [15:19]<drbobb> it's a gotcha but not a bug. [15:26]<drbobb> == comparison to booleans is a bad idea [15:36]<drbobb> [ ![]==true, []==false ]; evaluates to [false,true], for something yet a bit more glaringly confusing [15:39]<drbobb> oh well, broken-by-design