Re: [selectors-api] Minor comments on the spec text

> Philip Taylor wrote:
> > I'd also remove the "var rows = null;" and put the "var" inside the
> > loop to simplify the code, though perhaps that's a bad idea because
> > JS scoping is weird.

On 25/06/07, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Correct me if I'm wrong, but if it were declared inside the loop, the
> variable would be destroyed and reallocated in memory for every loop.
> By declaring it outside, it just allocates it once, which is more efficient.

Variable creation in ECMAScript always takes place before entering the
execution phase and continues until the closure is garbage collected.
In other words, variables are never destroyed and reallocated.
However, the lookup of the variable name will take place every time
through the loop (unless the engine optimises that, which I would be
surprised if a modern scripting engine didn't do). Dito the assignment
would take place every time though the loop.


Good coding style for ECMAScript places all variable declarations
before any non-initialisation code in the scope. That way developers
are less likely to get confused by the function scoping instead of
block scoping rules of ECMAScript. This goes particularly for examples
since far from all ECMAScript authors know the language well enough to
see what may be going wrong in their code, and most are taught by
looking at example code and going by trial and error after that.

To illustrate:
~~~~
    function addEventsToDiv(){
        // Declared where used
        for(var
i=0,elm,coll=document.getElementsByTagName('div');elm=coll.item(i);i++)
            elm.addEventListener('click',function(event){alert(i);},false);
    }
~~~~

As compared to:
~~~~
    function addEventsToDiv(){
        // First all local function declarations
        function fn(event){
            alert(i);
        }

        // Then all local variable declarations
        var
           elm,
           i=0,
           coll=document.getElementsByTagName('div');
        // ... including initialisations, but ONLY if those don't rely
on the rest of the
        // executable code. Otherwise the initialisation should be put
in the executable
        // code, separate from the declaration.

        // And finally the executable code
        while(elm=coll.item(i++)){
            elm.addEventListener('click',fn,false);
        }
    }
~~~~

The former is shorter in code, but the fact that the variable i is
scoped to the surrounding function and not the particular iteration is
far less obvious. Questions about this are quite common on JavaScript
forums and mailing lists.


The benfit to the functiondecl-vardecl-execode source ordering is that
it perfectly mimics the order things will be handled in the scripting
engine, and makes several scope related logic errors obvious.

> > Is it necessary to say that exceptions thrown inside
> > lookupNamespaceURI must propagate outwards to the selectElement
> > caller? Maybe that's obvious or is defined elsewhere.
>
> AIUI, exceptions continue to propagate until they are caught or result
> in an error.  I don't believe there is a need for me to specify that in
> this spec.

Exception handling can differ between languages, for example between
ECMAScript native and application native code. ECMAScript can throw
practically anything, but far from all languages can. An ECMAScript
exception thrown to application native code can result in an entirely
different exception, or a silent failure. I think it wouldn't hurt to
specify that an exception should be propagated (or rethrown?) out to
the caller.

> > Is it necessary to say what 'this' is, when nsresolver is a Function?
>
> I don't know.  I'd appreciate if someone who understands this issue
> better than I do could advise me.

It's not invoked as a method on anything, it doesn't make sense to
pretend that is is (unlike DOM Events, which for backward
compatibility makes sense to pretend are method calls on the target
element), so I'd say let the default take place. I.e. in ECMAScript
the this value would be the global object (window in browsers).
-- 
David "liorean" Andersson

Received on Monday, 25 June 2007 19:26:22 UTC