> On 7/27/07, liorean <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
