If got a couple of questions regarding this changeset:
1. Debug.write([void(0)]) will now print "[undefined]", beforehand it
was "[...]"
Undefined values were explicitly skipped prior to this change (see
i.e. LzDebug.as (old), ll.358: /"skip non-existent elements"/)
This behaviour has changed => intentionally or not?
2. Debug.write({length:'0'}) will now print "«Object#0| []»", beforehand
it was "{length: 0}"
Additional test for type of the length-attribute, "string" vs. "number"?
3. SWF vs. DHTML: to create a common code base, you've removed some
try..catch blocks (see LzDebug.js (old), l.462 to l.483)
Any disadvantages possible through this change?
4. SWF vs. DHTML: /"getter-heuristic"/ Debug#inspectInternal(..) resp.
Debug#objectOwnProperties(..),
less tests in SWF and removed
try..catch in DHTML, no disadvantages at all for this?
SWF:
if ((! hasProto) ||
obj.hasOwnProperty(key) ||
// attached movie clips don't show up as 'hasOwnProperty' (but
// hasOwnProperty is more accurate -- consider if an instance
// copies a prototype property)
(obj[key] !== obj.__proto__[key]) ||
// or getter slots (this is a heuristic -- there is no way to
// ask if a property is a getter)
*(obj.__proto__.hasOwnProperty(key) &&
(typeof(obj.__proto__[key]) == 'undefined'))*
)
DHTML:
if ((! hasProto) ||
obj.hasOwnProperty(key) ||
// or getter slots (this is a heuristic -- there is no way to
// ask if a property is a getter)
*(function () { try { return obj[key] } catch (e) {} })() !==
(function () { try { return obj.constructor.prototype[key] }
catch (e) {} })()*
)
NEW:
if ((! hopp) ||
obj.hasOwnProperty(key) ||
// Heuristic to find getter slots (there is no way to ask if a
// property is a getter)
(proto && (obj[key] !== proto[key])))
5. Debug#__String(..): changes for treatment of objects with a (numeric)
"length" property.
Beforehand: any object with a numeric length property was
treated as an array, "toString()" was never called,
see i.e. LzDebug.as (old), l.349 and ll.376
Now: if any object has got an own "toString()" method, it will
called, so no treatment as an array,
see i.e. LzDebug.as (new), ll.348 and ll.360
Good change, but do we need to document it?
Improvements:
- LzDebug.as, l.349 (new), "(thing['toString'] instanceof Function) &&"
==> "(thing.toString instanceof Function) &&"
- LzDebug.as, l.563 (old), "var kl = keys.length;", LzDebug.as, l.541
(new), "var kl = names.length;"
"kl = [k]eys.[l]ength", but "kl = names.[l]ength"? (also for "var
kil" and the same vars in LzDebug.js)
Could be changed for clarification...
Bug?:
- LzDebug.js, l.289 (new), "(this.toString instanceof Function)" should
be "(thing.toString instanceof Function)"!?
P T Withington wrote:
[André, if you are not up for reviewing this, let me know and I will
get someone else, but I thought you might be an interested party...]
Change 20070930-ptw-P by [EMAIL PROTECTED] on 2007-09-30
18:01:29 EDT
in /Users/ptw/OpenLaszlo/ringding-2
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: Don't trust length as an indicator of array elements
Bugs Fixed:
LPP-4441 'Debugger misbehaves when debugging objects with "length"
attribute.'
Technical Reviewer: [EMAIL PROTECTED] (pending)
QA Reviewer: hminsky (pending)
Doc Reviewer: jsundman (pending)
Documentation:
NOTE: If you have Firebug enabled in Firefox, the LZX debugger echos
all messages to the Firebug console, preserving objects. The Firebug
debugger will attempt to interpret an object with a `length` field as
an array and try to print every array element. This may cause a
'Script Running Slowly' error. Disabling Firebug will prevent that.
Details:
Don't trust length to indicate how many properties are in an
object (or elements in an array). Instead, get the properties
from the object using `for ... in`. We still present any object
with a `length` property that is non-negative as an array, but we
won't try to iterate through the entire array. This is useful for
sparse arrays, but also for objects that just happen to have a
non-negative length property.
LzDebug.lzs: Added Debug.objectOwnProperties that gets the names
of all the 'own' properties of the object. If the object has a
non-negative `length` property, accumulate the properties that are
between 0 and that length in a separate list of indices.
LzDebug.{as,js}: Use that to print and inspect objects and arrays
without falling into the trap of iterating from 0 to length.
Basically, the old presentation style is preserved, but we iterate
_only_ over the properties the object actually has.
Tests:
lzx> Debug.write({1: 'one', 97: 'ninety-seven', a: 'eh?', floogle:
'snort', length: 100000000, __proto__: {bar: 'bletch'}})
«Object(100000000)#127| [..., one, ..., ninety-seven]»
lzx> Debug.inspect([..., one, ..., ninety-seven])
«Object(100000000)#127| [..., one, ..., ninety-seven]» {
a: 'eh?'
floogle: 'snort'
length: 100000000
1: 'one'
97: 'ninety-seven'
}
[..., one, ..., ninety-seven]
lzx>
Above completes without "Script Running Slowly". Tested in SWF
and DHTML (with Firebug disabled, see Documentation NOTE above).
smokecheck passes in DHTML and SWF (which tests Debug.format,
which uses __String, showing that the expected presentation is
preserved).
Files:
M WEB-INF/lps/lfc/debugger/LzDebug.lzs
M WEB-INF/lps/lfc/debugger/platform/swf/LzDebug.as
M WEB-INF/lps/lfc/debugger/platform/dhtml/LzDebug.js
Changeset:
http://svn.openlaszlo.org/openlaszlo/patches/20070930-ptw-P.tar
