Ever wondered why the fdb command line debugger appends a number to each result it gives back to you ?
Turns out, it's because you can use that to refer back to the result again, which saves retyping or cut'n'paste when your are drilling down.
Here's an example:
(fdb) print event
$12 = [Object -644987999, class='mx.events::DragEvent']
(fdb) print $12.dragSource
$13 = [Object -645755775, class='mx.core::DragSource']
(fdb) print $12.dragSource.
$14 = dragSource = [Object -645755775, class='mx.core::DragSource']
_formats = [Object -646648863, class='Array']
dataHolder = [Object -645756223, class='Object']
formatHandlers = [Object -645755647, class='Object']
formats = [Object -646648863, class='Array']
VERSION = "3.0.0.0"
(fdb) print $14._formats.
Value 'For input string: "dragSource = [Object -645755775, class='mx.core::DragSource']
_formats = [Object -646648863, class='Array']
dataHolder = [Object -645756223, class='Object']
formatHandlers = [Object -645755647, class='Object']
formats = [Object -646648863, class='Array']
VERSION = "3.0.0.0""' could not be converted to a number
Expression could not be evaluated.
Note how I start out dumping the 'event' object. Next I want to see the 'dragSource' property, so rather than typing 'print event.dragSource' I can just enter the variable name ($12) followed by the property. Note how it even honors the 'trailing dot' syntax ([node:1380]) to inspect the properties of 'dragSource'.
Sections