liorean wrote:
On 25/06/07, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
Philip Taylor 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. [...]
Thanks for the explanation.
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,
Yes, I'm aware of that.
I think it wouldn't hurt to specify that an exception should be
propagated (or rethrown?) out to the caller.
Do any other specs specify such a requirement for exception handling?
Surely, if it were necessary to state that, it should be in DOM Level 3
Core where DOMException is defined, instead of in each individual spec
that uses exceptions.
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-17189187
I added explicit references to DOM 3 Core, where the exceptions are
mentioned.
Is it necessary to say what 'this' is, when nsresolver is a
Function?
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).
OK, that makes sense.
--
Lachlan Hunt
http://lachy.id.au/
