Closure bug
in [JavaScript]
|
Prev: Microsoft Visual Web Developerr
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-05-17)
From: Lasse Reichstein Nielsen on 24 May 2010 14:12 Richard Cornford <Richard(a)litotes.demon.co.uk> writes: > On May 24, 5:22 pm, Lasse Reichstein Nielsen wrote: >> 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). > > 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? 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 -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: John G Harris on 25 May 2010 11:22
On Mon, 24 May 2010 at 03:58:52, in comp.lang.javascript, Richard Cornford wrote: >On May 23, 11:52 am, John G Harris wrote: <snip> >> 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. 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.) <snip> >> 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). <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 -- John Harris |