Question about joined function object of ECMA-262 3rd edition

liorean liorean at gmail.com
Fri Jul 27 05:26:25 PDT 2007


> On 7/27/07, liorean <liorean at gmail.com> wrote:
> > x()===y() may return false the same way x()===x() may return false.
> > Functions in JavaScript may have side effects, and the same input
> > doesn't necessarily give the same output in cosecutive uses of the
> > function.

On 27/07/07, Shijun He <hax.sfo at gmail.com> wrote:
> No, I don't mean side effect, and there is no side effect in this
> case. The result may be not equal just because they have diff
> [[Scope]].

The function objects may not be joined if the they are dependent on
different scopes. They may only be joined under the circumstance that
the difference in scopes does not give a difference in observable
behaviour.



> On 7/27/07, liorean <liorean at gmail.com> wrote:
> > Functions with different scope may be joined, but only if the scope
> > difference will lead to no externally observable difference.

On 27/07/07, Shijun He <hax.sfo at gmail.com> wrote:
> Could you point out in where the spec defines such condition?
>
> The spec only says: ...an implementation may detect when the
> differences in the [[Scope]] properties of two or more joined Function
> objects are not externally observable and in those cases reuse the
> same Function object rather than making a set of joined Function
> objects.
>
> My impression of it is: if the differences in the [[Scope]] are
> externally observable, then the implementation can't reuse the same
> object, but can make a set of joined Function objects.

I think the meaning is rather that of: "If implementing joined
functions, engines may instead simply reuse the same function object"
than of "For this special case of joined functions, an engine may
reuse the same function object" because of the wording of the prior
and next sections.

~~~~
13.1.1 Equated Grammar Productions
•  Both uses obtained their FunctionBody from the same location in the
source text of the same ECMAScript program. This source text consists
of global code and any contained function codes according to the
definitions in section 10.1.2.
/.../

10.1.2 Types of Executable Code
There are three types of ECMAScript executable code:
•  Global code is source text that is treated as an ECMAScript
Program. The global code of a particular Program does not include any
source text that is parsed as part of a FunctionBody.
/.../
•  Function code is source text that is parsed as part of a
FunctionBody. The function code of a particular FunctionBody does not
include any source text that is parsed as part of a nested
FunctionBody. /.../
~~~~

I.e. if a nested function relies on the containing function, the code
it relies on is not part of either the global code or it's contained
function code and in other words can't be equated.

~~~~
13.2 Creating Function Objects
/ - - - /
Step 1 allows an implementation to optimise the common case of a
function A that has a nested function B where B is not dependent on A.
In this case the implementation is allowed to reuse the same object
for B instead of creating a new one every time A is called. Step 13
makes this optimisation optional; an implementation that chooses not
to implement it will go to step 2.
~~~~

Note "where B is not dependent on A" and "an implementation that
chooses not to implement it will go to step 2".

As I understand it, this part of the spec was written with that
particular optimisation in mind. Joined objects are just a way for the
specification to allow it.


Also, IMO it's one part of the spec that should be removed in ES4. It
makes the semantics of certain valid ES3 programs ambiguous.
-- 
David "liorean" Andersson


More information about the Es4-discuss mailing list