Closure bug

[John G Harris]

The words that actually say what exactly? There are no words in the
spec that say "can ... conclude", the ability to do that as a result
of the observation is evidently a fact (as at least one person has
done so).

Yes, I didn't say it very clearly. I want to know which words in ECMA
262 say that you can get at the insides of the same object via two
different variables. I've finally managed to plough through the many
sections of the standard needed to find the answer.

Suppose you execute these two statements :

b = new Object();
c = b;

and follow the formal ES3 definitions of what will happen. After tracing
through all the gets, puts, returns, etc. you will find that the 'value'
of b *is* the newly created object, and the 'value' of c is also that
same object. Thus any change to the insides of the new object made via b
is also visible via c.

Obviously, the meaning of 'value' in ECMAScript is somewhat different to
its meaning in other languages.

If 'value' seems confusing then we can turn to the informal ES3 Overview
section where properties are said to be containers. Each property, and
so each variable, is said to contain either a primitive value or an
object. Thus both b and c contain the same newly created object in the
same way that both New York and North America contain Wall Street.
Unlike real geography, an object can indirectly contain itself, making
life difficult for the garbage collector.

If you ask whether function arguments are passed by this or by that or
by something else in ECMAScript the only correct answer is that all
arguments are passed by containment. Any disagreement can only be about
which feature of which other language it most closely resembles.

The ES5 standard adds much complication to the formal definitions but
appears to make no essential difference to these conclusions.

John

 

[Richard Cornford]

Yes, I didn't say it very clearly. I want to know which words
in ECMA 262 say that you can get at the insides of the same
object via two different variables. I've finally managed to
plough through the many sections of the standard needed to
find the answer.

That will save me having to look up all the references in that spec.

Suppose you execute these two statements :

b = new Object();
c = b;

and follow the formal ES3 definitions of what will happen. After
tracing through all the gets, puts, returns, etc. you will find
that the 'value' of b *is* the newly created object, and the
'value' of c is also that same object. Thus any change to the
insides of the new object made via b is also visible via c.

Obviously, the meaning of 'value' in ECMAScript is somewhat
different to its meaning in other languages.

Probably at least some other languages, maybe most (I don't want to
think about that at the moment). We have a situation where a value can
be an object; the object *is* a value. We can be pretty sure, from
experience of how computers work, that an implementation is going to
be achieving that by employing some sort of reference, but that isn't
a concern of ECMAScript itself. ECMAScript stops at asserting that
objects are values.

If 'value' seems confusing then we can turn to the informal ES3
Overview section where properties are said to be containers.
Each property, and so each variable, is said to contain either
a primitive value or an object. Thus both b and c contain the
same newly created object in the same way that both New York
and North America contain Wall Street.

Wouldn't you b and c example above be better paralleled with, say,
Boston and New York both containing Wall Street?

Unlike real geography,

I don't think geography is going to prove that useful in this case.

an object can indirectly contain itself,
making life difficult for the garbage collector.

If you ask whether function arguments are passed by this or by
that or by something else in ECMAScript the only correct answer
is that all arguments are passed by containment.

Are they? If we accept 'properties "contain" values (so may contain
objects as objects are values)' then if the mechanics of passing
arguments to function calls does not involve properties of objects (at
any distinct step) then they will not be contained at that point, and
may not be being "passed by containment". (I may propose that at the
point of the having the result of the call to the internal GetValue
function in the algorithm for evaluating an Arguments list (11.2.4
(3rd Ed.)) represents having only the value, without any 'container'.)

Suppose we attempt to address this question form the other end, and
instead of worrying about how an argument is passed to a function call
instead look at how a function call receives its arguments. In
ECMAScript terms a function call always 'receives its arguments as
(ECMAScript) values'. This is guaranteed by the GetValue call in the
Arguments list algorithm, and it is here that the implications for the
possible 'passing on' of - this - values come from (there can be no
Reference types received as arguments to function calls).

Any disagreement can only be about which feature of which
other language it most closely resembles.

While that disagreement is evident I doubt that will prove the "only"
subject of disagreement.

The ES5 standard adds much complication to the formal definitions
but appears to make no essential difference to these conclusions.

That is my impression too.

Richard.

 

[Richard Cornford]

Richard Cornford wrote:

You mean e.g. and not i.e.

I may have meant e.g., if I could think of a single other example.

Richard.

 

[Tim Streater]

I may have meant e.g., if I could think of a single other example.

That *you* can't/couldn't think of another example makes no difference.

 

[Lasse Reichstein Nielsen]

I may have meant e.g., if I could think of a single other example.

Other examples:

The operands or result of any bitwise operation other than >>>, which
needs a 32-bit unsigned integer for the result (but you can ignore
that if it's used as operand of another bitwise operation).

The return value of String.prototype.charCodeAt. (The problem is
to recognize that that is the function being called).

/L

 

[Richard Cornford]

Other examples:

The operands or result of any bitwise operation other than
(but you can ignore that if it's used as operand of another
bitwise operation).

I assume you mean numeric literal operands. So if - x|0 - there is no
need to create an IEEE double from the '0' as a 32 bit (or even
smaller) integer will do? It is not nearly so easy to do that for the
'x'.

The return value of String.prototype.charCodeAt. (The problem
is to recognize that that is the function being called).

When you do a math operation with that return value don't you need to
be checking its type in order not to handle it as an IEEE double
precision floating point number? Then, isn't there an implied overhead
of extra type checking for all math operations?

Richard.

 

[Lasse Reichstein Nielsen]

On May 24, 5:22 pm, Lasse Reichstein Nielsen wrote:

I assume you mean numeric literal operands. So if - x|0 - there is no
need to create an IEEE double from the '0' as a 32 bit (or even
smaller) integer will do? It is not nearly so easy to do that for the
'x'.


When you do a math operation with that return value don't you need to
be checking its type in order not to handle it as an IEEE double
precision floating point number? Then, isn't there an implied overhead
of extra type checking for all math operations?

Yes to both. You need to know both how a value is produced and how
it's going to be used, so that you know whether it is a 32-bit
integer, and whether you can keep it as a 32-bit integer until it is
consumed - without needing runtime checks in either end.

This is on top of using a dual representation of numbers: small
integers for the values that can fit, and full doubles for the
rest. For this, you need a tagging mechanism, and a runtime check
before using any value. In practice, most of the actual values in
Javascript programs turns out to be small integers, and the more
efficient representation saves more than the overhead of tagging.

/L

 

[John G Harris]

On May 23, 11:52 am, John G Harris wrote:


Wouldn't you b and c example above be better paralleled with, say,
Boston and New York both containing Wall Street?


I don't think geography is going to prove that useful in this case.

I was trying to point out that it is possible for two different things
to have the same point in common. A Venn diagram is a better example but
I thought New York would be better known. (Is North America as well
known? I wonder.)

Are they? If we accept 'properties "contain" values (so may contain
objects as objects are values)' then if the mechanics of passing
arguments to function calls does not involve properties of objects (at
any distinct step) then they will not be contained at that point, and
may not be being "passed by containment". (I may propose that at the
point of the having the result of the call to the internal GetValue
function in the algorithm for evaluating an Arguments list (11.2.4
(3rd Ed.)) represents having only the value, without any 'container'.)

Suppose we attempt to address this question form the other end, and
instead of worrying about how an argument is passed to a function call
instead look at how a function call receives its arguments. In
ECMAScript terms a function call always 'receives its arguments as
(ECMAScript) values'. This is guaranteed by the GetValue call in the
Arguments list algorithm, and it is here that the implications for the
possible 'passing on' of - this - values come from (there can be no
Reference types received as arguments to function calls).

<snip>

It's what the function's code sees that matters. According to the formal
description, it sees values that have been passed on by several Returns,
held in a sequence of values, and have finally landed inside the
properties of the arguments object and inside local variables (which are
also properties).

It's what the code sees in those properties that determines what kind of
'pass-by-' is happening.

John