[Javascript] Object reference usage (was Javascript and FF)

[Paul Novitski]

At 8/31/2009 07:02 AM, Mike Dougherty wrote:
>given a tree-like object:
>myObjRoot.Region["East"].City["NewYork"].Office["NY315"].Manager["ABC"].Agent["DEF"].FirstName
>= "Frank";
>
>should (in your opinion) we do this:
>var agent = 
>myObjRoot.Region["East"].City["NewYork"].Office["NY315"].Manager["ABC"].Agent["DEF"];
>agent.FirstName = "Frank";

No (see below).


>Does it cost anything* to make the variable reference for a single
>property assignment?
>Does it cost anything* to use the unwieldy but very explicit reference
>from root for several assignments?
>
>* cost anything: in terms of resource overhead in memory or CPU such
>that would be prohibitive to run inside a loop (for one example of
>exacerbating a performance issue)  or is the performance cost
>negligible compared to increased  readability of the source?


I don't know enough of the low-level details of the JavaScript 
engine(s!) to be able to give an expert opinion on this point. My 
common sense expectation is that creating & deleting variables 
without penalty has got to be one of the fundamental processes in a 
language interpreter that allows for local scope, and I likewise 
assume that using a variable to hold an object reference is much 
cheaper in processor cycles than recomputing the same parent-child 
look-up repeatedly, but it sounds like you're looking for something 
more authoritative than a 'common sense' opinion.

My take on this subject pertains almost entirely to bulletproofness. 
I avoid statements that make untestable assumptions about the 
dataset. If you run this script:
_______________________

         var myObjRoot = new Object();

         alert('1: ' + myObjRoot);

         var agent = 
myObjRoot.Region["East"].City["NewYork"].Office["NY315"].Manager["ABC"].Agent["DEF"];
agent.FirstName = "Frank";

         alert('2: ' + myObjRoot);
_______________________

...you get the first alert but not the second because JavaScript 
aborts with 'Error: myObjRoot.Region is undefined.' This is a mere 
data omission that results in termination of the language 
interpreter! Naughty scripter! Bad!

I realize that your example is deliberately forced and isn't likely 
to appear in mature code as is, but it brings up a stylistic flaw I 
see in lots of code out there.

I endeavor always to test for the existence of an object before 
referring to its children. Here's a hypothetical example that grabs 
the content of the second paragraph in the header of a document:
_______________________

NOT:
         var sContent = 
document.getElementById('header').getElementsByTagName('p')[1].firstChild.nodeValue;

_______________________

INSTEAD:
         var oHeader = document.getElementById('header');
                 if (!oHeader)
                 {
                         return alert("Can't find header");
                 }
         var aParas = oHeader.getElementsByTagName('p');
                 if (aParas.length < 2)
                 {
                         return alert("Can't find second paragraph");
                 }
         var oContent = aParas[1].firstChild;
                 if (!oContent)
                 {
                         return alert('Paragraph is empty');
                 }
         var sContent = oContent.nodeValue;
_______________________

(Those return alerts are purely for logic illustration and aren't 
what I do in production code.)

I work like this to make my code durable and easy to read and modify. 
It does end up that I use a lot of transient variables to hold 
objects during the drill-down, and I certainly hope that I'm not 
hosing the processor by doing so. I've never experienced any 
perceptible latency by coding in this way, but then my JavaScript 
usage tends to be light touches and not long involved applications 
that might more likely challenge the processor if JavaScript doesn't 
create temp variables efficiently or the heap if garbage collection 
isn't up to snuff.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com