;functionDeclaration fashion ?

[RobG]

On Sep 28, 7:12 pm, kangax wrote: [...]

Another obvious difference here is that Identifier of function
always references same object as new execution contexts (of inner
functions) are entered (unless it is shadowed by local variables,
of course), whereas `arguments.callee` doesn't.
(function foo(){
   (function(){
     // `arguments.callee` and `foo` reference different object
   })();
})();

While that is true, I don't see the point/problem. In a world without
- arguments.callee - the inner function could be given an Identifier
and referred to by name, and in a world where giving function
expressions Identifiers is impractical the - arguments.callee - could
be assigned to a variable in the outer function and then the outer
function called from the inner. So the above could be inverted as:-

(function(){
   var argCallee = arguments.callee;
   (function bar(){
     // `bar` and `argCallee` reference different object
   })();
})();
Absolutely.

Yes, you have mentioned that before. Incidentally "one of the first"
is a bit of an odd attribution, particularly about a 2007 post on a
subject that I was told about sometime around 2003.

I suppose I didn't find earlier references at that time. If you have
one, I'll update article accordingly.

You might also include a reference to the discussion between Richard
and YEP in the thread below. It seems to be the first discussion of
"conditional" function declarations (mentioned in your article) on clj
in August 2003:

"Priveleged method gotcha"
<URL: http://groups.google.com/group/comp.lang.javascript/msg/ead861ed55dc1b9c
And includes a brief discussion of IE's issues - read the last by YEP,
where he shows IE may evaluate named function expressions twice (which
might also explain related behaviour).

 

[Dmitry A. Soshnikov]

On 28 Ñен, 22:12, kangax <[email protected]> wrote:

[...]

The other thing optional name is better - in theory (by algorithm) it
should be resolved faster than e.g. external identifier binding
referenced to function object (as the object held optional name of FE
regarding Scope is in front of [[Scope]], right after activation
object). But it should be resolved slower that arguments.callee as
arguments-object is in activation object (but with doubt, as
also .callee property should be got - and it's also time).

Actually, mere occurence of `arguments.callee` usually results in
decreased performance as some (newer) engines tend to create `callee`
lazily on its first access (and, IIRC, ditto for the `arguments` object).

Ah, maybe, didn't know that, thx for info. But, I mostly was talking
about theoretical algorithms, independent implementations. Lazy
instantiation for |arguments| and its properties seems to me a good
idea.

But this non-standard handling of NFE in IE is really damned. Was it
so hard to remove that object held the name of FE after the FE is
created? For what they (IE) put this name right into variable/
activation object (and even create different object)? - that's really
strange, I don't see the explanation (more than, they forbid
[[Delete]]-ing properties of the host objects - it's not possible even
to delete that not needed optional name which is VO/AO now; null-ing
maybe will remove object by GC, but will leave the property name).

IE parses NFE as if it was a function declaration, so I would assume it
creates a DontDelete'able binding (as any other function declaration). I
can't be sure though. I was never really concerned with this.

IE sets {DontDelete} for every property of host object, e.g. for
window object.

var a = 10; // {DontDelete} by the spec as it's variable, OK
b = 10; // should be no {DontDelete}, as it's only property, not a
variable

but in IE it's not possible to delete |b| also:

delete b; // false, |b| will still exists

I'm not sure what you mean. Are you talking about ES5 strict mode?

Yes, exactly. And have meant that |.callee| is still optional, but in
strict mode FE should always has name and |arguments.callee| will
throw an exception.

ES committee knows about NFE problem in IE, but I think everyone expects
IE to fix these discrepancies when they introduce ES5-conforming
implementation.

Yeah, I think (and hope ) so.

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov wrote:
On 28 Ñен, 22:12, kangax <[email protected]> wrote: [...]

The other thing optional name is better - in theory (by algorithm) it
should be resolved faster than e.g. external identifier binding
referenced to function object (as the object held optional name of FE
regarding Scope is in front of [[Scope]], right after activation
object). But it should be resolved slower that arguments.callee as
arguments-object is in activation object (but with doubt, as
also .callee property should be got - and it's also time).
Actually, mere occurence of `arguments.callee` usually results in
decreased performance as some (newer) engines tend to create `callee`
lazily on its first access (and, IIRC, ditto for the `arguments` object).

Ah, maybe, didn't know that, thx for info. But, I mostly was talking
about theoretical algorithms, independent implementations. Lazy
instantiation for |arguments| and its properties seems to me a good
idea.

But this non-standard handling of NFE in IE is really damned. Was it
so hard to remove that object held the name of FE after the FE is
created? For what they (IE) put this name right into variable/
activation object (and even create different object)? - that's really
strange, I don't see the explanation (more than, they forbid
[[Delete]]-ing properties of the host objects - it's not possible even
to delete that not needed optional name which is VO/AO now; null-ing
maybe will remove object by GC, but will leave the property name).
IE parses NFE as if it was a function declaration, so I would assume it
creates a DontDelete'able binding (as any other function declaration).I
can't be sure though. I was never really concerned with this.

IE sets {DontDelete} for every property of host object, e.g. for
window object.

Not really.

window is only **one host object**. The fact that setting property on
window (and specially via undeclared assignment) results in that
property having {DontDelete} attribute, doesn't really mean that every
other host object behaves that way, does it?

document.foo = 1;
delete document.foo; // true
document.foo; // undefined

(in IE8 that is)

document is host object too, as I'm sure you know.

Yes, thanks for correction, I've exactly meant |window| object (said
not correctly). Even better to say that |window| don't allow (not
supports) [[Delete]] operation for properties if to try to delete
explicitly via |delete window.someProperty|.

[...]

                                   DontEnum ReadOnly DontDelete

created_via_var_declaration       true     false   true
created_via_func_declaration      true     false   true
created_via_property_assignment   false    false    Error
created_via_undeclared_assignment true     false    Error

Have you seen this recent thread?

<http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...>

Nope, will see, thanks for reminding the IE's internal properties
handling table, but I see some strange things yet (will show bellow).

DontEnum ReadOnly DontDelete

created_via_undeclared_assignment true false Error

Here's one crazy-head thing in IE (at least in IE8):

If to delete undeclared assigned property implicitly (without |window|
object prefix), that's OK (and that means I missed myself with example
above):

b = 10;
alert(b);
delete b;
alert(b); // "b" is not defined

Or event:

b = 10;
alert('b' in window); // true

Or:

b = 10;
delete b;
alert('b' in window); // false

But bellow, that bug-things are:

b = 10;
alert('b' in window); // true, OK, as we see it above
delete b;
alert('b' in window); // true, again true? but we see above false
after that

// the most buggy-thing
alert(b); // **out of memory**, not "b" is not defined