On 11/13/2016 12:33 PM, Isiah Meadows wrote:
> Okay. Is it a spec bug then? Throwing a ReferenceError is surprising and odd
> IMHO.
I think so -- having different sorts of early errors makes it a little less
clear what sort of error should be thrown when two early errors of different
types are
On 09/27/2016 05:38 AM, Bob Myers wrote:
> To my knowledge no-one has ever explained why the following is a bad idea:
>
> ```
> array.0
> array.-1
> ```
Consider this already-valid code:
var first = array
.0.toString();
This parses *right now* as
var first = array;
(0.0).toString();
On 02/26/2015 09:54 AM, Mark S. Miller wrote:
Jeff?
To be completely honest, I can't answer this. My message was merely to pass
along the sentiments of others, observed elsewhere, not previously communicated
to this list. I personally don't understand what we're doing at a low level
And expanding scope slightly: IntegerIndexedElementGet -- get -- throws a
TypeError if the relevant typed array is detached, rather than just returning
|undefined| as the computed value. I understand there are also significant
complaints about this, for similar reasons.
Jeff
On 10/31/2014 08:40 AM, Katelyn Gadd wrote:
In my testing, even best-case optimized memcpy/memset loops did not
produce the kind of efficient code you want. There were always bounds
checks and in some cases I saw other overhead. The set/copy definitely
weren't vectorized. In the best case I
On 10/28/2014 09:10 AM, Andreas Rossberg wrote:
If so, how do we fix this? Allowing shadowing after the fact is pretty
bad, since it will probably make all accesses to builtin globals
slower in ES6. But it is particularly bad for 'undefined', where the
ability to rebind would break various
I was just tracing through typed array construction behavior, and it looks to
me like |new Uint8Array()| creates an object via OrdinaryCreateFromConstructor,
not by delegating to %TypedArray%.[[CreateAction]]. This creates an object
with the right prototype chain but none of a typed array's
On 10/17/2014 01:53 PM, Erik Arvidsson wrote:
[1] Microsoft Outlook Calendar web app (part of Exchange Outlook Web Access)
Microsoft could ship a fix in a point release, right? They surely already
provide security patches that admins must install anyway, if they want to keep
their users (and
Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that throws
a TypeError if |this| doesn't have the internal slots of a typed array.
Neither %TypedArray%.prototype nor {{Ui,I}nt{8,16,32},Float{32,64}}.prototype
have these internal slots. So the builtin Object toString
On 08/12/2014 11:07 PM, Allen Wirfs-Brock wrote:
sounds good to me, I'll update the spec. accordingly
On Aug 12, 2014, at 7:39 PM, Erik Arvidsson wrote:
I was suggesting that String(symbol) should not throw.
This can be spec'ed as String( value ) checking the Type of the value and
special
On 08/26/2014 08:48 AM, Domenic Denicola wrote:
Why would it be useful, from a programmer's perspective, to expose ToString
directly?
People will always want to polyfill, or prototype in advance of proposal for
standardization. No matter how internal the operation might be, it's heavily
On 08/26/2014 09:14 AM, Brendan Eich wrote:
Claude Pache wrote:
Personally, I use the following expression in order to coerce a variable to
a string:
var obj = this + ''
and its in-place variant:
x += ''
I think it'll continue to work in ES6.
Agreed, this is the
On 06/12/2014 03:05 PM, Allen Wirfs-Brock wrote:
I believe this behavior for for-in was added in ES5. My recollection was
that Doug Crockford pushed for it. I don't recall if it was because it
matched web reality or simply because he thought it was a good idea.
It was added for web
On 06/12/2014 03:25 PM, Brendan Eich wrote:
Actually, if memory serves, IE JScript tolerated null and undefined on right
of for-in. SpiderMonkey and my ur-JS implementation, Mocha, did not. Someone
with the jwz nostalgia Netscape 2/3 browsers, please test.
Hmm. I'm reciting tribal knowledge
I dunno if this'd be useful to anyone else or not (mentioning here to see
whether anyone else sees value in this). But would it be possible for drafts
to include the draft date in page headers, or overall PDF title, or somewhere
easily-viewable without scrolling too far from any position in
var n = 0O755;
Is this something anyone wants to read? I certainly don't! Allowing only
lowercase 'o' in octal literal syntax is inconsistent with 'x' and 'b', but on
balance I think that's probably preferable to admitting this monstrosity. :-)
(Which isn't to say I care strongly enough to
On 07/12/2013 04:59 PM, Andrea Giammarchi wrote:
one more thing ... I believe this will impact arrow function too since is
basically bound callbacks all over the place (or at least this is how I
believe it will be transpiled)
Sadly, based on the arrow-function patches I've reviewed in
On 07/12/2013 02:54 PM, Allen Wirfs-Brock wrote:
Looking at it another way, if implementation haven't found it straightforward
to optimize ES5 bound functions why would you expect that would have an
easier time with Proxys?
I'm pretty sure no implementation has seriously tried to optimize
On 07/13/2013 12:56 PM, Allen Wirfs-Brock wrote:
On Jul 13, 2013, at 12:39 PM, Mark S. Miller wrote:
Arrow functions, whether strict or non-strict, are not supposed to have
their own |arguments|
Correct. Implementors should be aware that in the current ES6 draft this is
stated in a
On 07/12/2013 10:27 AM, Tab Atkins Jr. wrote:
And, because of what we discussed in the recent thread...
Number.isInteger(Math.pow(2,53)-1) == true
Number.isInteger(Math.pow(2,53)) == false
I need to comment in the other thread again and push back against what people
have said there, but
On 07/09/2013 06:49 PM, Mark S. Miller wrote:
Because Nat includes 2**53, this code actually fails to enforce conservation
of currency!!
The problem isn't that Nat includes 2**53. It's that you're performing an
operation that may compute an inexact value, then you're treating that inexact
On 07/12/2013 04:03 PM, Allen Wirfs-Brock wrote:
are you suggesting that if we want such an function, it should be named
something else, such as isExactInteger, isPreciseInteger,
isUnambiguousInteger, etc?
Possibly, but I don't think so. Whether a value is exact or precise is a
function
On 07/12/2013 04:13 PM, Tab Atkins Jr. wrote:
If you don't agree with that reasoning, then I suppose you'd argue
that *all* numbers 2^53 should return true, since they're all forced
into being represented as integers?
All numbers = 2**53 except Infinity, yes. I think isInteger implies the
On 07/12/2013 04:09 PM, Tab Atkins Jr. wrote:
Mark's Nat() function *does* throw if the input isn't an
exactly-representable number.
Yes. I'm arguing that's not helpful when you can compute an
exactly-representable number, that is the result of an inexact calculation,
like |Math.pow(2, 53) +
On 07/12/2013 04:32 PM, Allen Wirfs-Brock wrote:
So the other thread was a discussion concerning the appropriate value of
Number.MAX_INTEGER. Do you think it should be 2^53-1, or 2^53, or the same
thing as Math..MAX_VALUE.
Number.MAX_INTEGER should be 2**53. People who want 2**53 - 1 (and
On 07/12/2013 04:56 PM, Allen Wirfs-Brock wrote:
So you seem to be saying that that
Number.isInteger(MAX_VALUE) should be true, but that Number.MAX_VALUE
Number.MAX_INTEGER is also true because for isInteger you using the
mathematical definition of Integer but for MAX_INTEGER you are
On 07/12/2013 04:53 PM, Mark S. Miller wrote:
I would like a better API -- both less likely to be used unsafely and no
harder (or not much harder) to use safely. Suggestions?
In C++ you'd want MS's SafeInt, or WTF's CheckedInt, with operator overloading
and all that jazz. Without operator
On 07/12/2013 06:17 PM, Tab Atkins Jr. wrote:
On Fri, Jul 12, 2013 at 5:15 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
While I sympathize with the desire to make integer mean mathematical
integer, I don't think it's going to work out very well. Nobody actually
cares about such
I'm only commenting on the proposals that seem to be in the current draft,
because I'm reviewing a patch that adds only those particular constants. :-)
Just to be clear why I'm saying nothing about the other constants, neither to
praise nor to disparage.
On 03/09/2012 08:00 PM, Roger Andrews
On 05/07/2012 01:31 PM, Allen Wirfs-Brock wrote:
added Number.EPSILON,MAX_INTEGER,parseInt, parseFloat,isNaN,isFinite,
isInteger, toInt
Modulo the semantic quirks in my last response, talking about the values and
intended meanings of EPSILON and MAX_INTEGER, I think it would be better to
On 07/09/2013 04:14 PM, Brendan Eich wrote:
Why pick this particular epsilon? Why not, say, 2**-1074 instead, as the
difference between 0 and the next largest number? Seeing only the name I'd
have guessed 2**-1074.
See http://en.wikipedia.org/wiki/Machine_epsilon.
Hmm, my memory of the
On 05/09/2013 10:12 AM, Brendan Eich wrote:
Adding an equivalent to the main spec does not cordon off the mis-performing
(non-performant?) functionality.
I may have misread, but I had thought there was argument to put
Object.setPrototypeOf in Annex B as well. If it's added, that seems like
On 05/08/2013 01:58 PM, Brendan Eich wrote:
1. Dumping stuff into Annex B to show disdain. This is pride, bad for the
soul.
Pride doesn't seem like a reason one way or the other, to me. The reason
would be to cordon off functionality whose mis-performance developers will not
intuitively
On 05/08/2013 04:10 PM, Brendan Eich wrote:
Why would Object.setPrototypeOf have any better perf?
It wouldn't.
developers will not intuitively understand, so that they're less likely to
use it. Some will, even still, perhaps just out of obstinacy (pride,
I think you missed that that
To clarify, since I was perhaps somewhat terse here. :-)
print(eval('[{__proto__: 17}]')[0].hasOwnProperty(__proto__));
print(eval('[{__proto__:0x17}]')[0].hasOwnProperty(__proto__));
SunSpider uses eval() on JSONish input, so engines have to make that fast.
Most/all engines for
On 04/21/2013 03:27 PM, Mark S. Miller wrote:
Warning: The following is a sickening idea. I would really hate to see us do
it. But I feel obliged to post it as it may in fact be the right thing to do.
This suggests that, in JS as well, the __proto__ in {, __proto__:
, } not be
The current steps call the [[Delete]] method on the array with property
length and assign the result to deleteStatus, ReturnIfAbrupt(deleteStatus),
throw if strict mode and !deleteStatus, then return true. Should that last
return-true have been |return deleteStatus| instead?
Jeff
On 04/02/2013 12:13 AM, Tom Van Cutsem wrote:
The true/false return protocol doesn't prevent exceptions to be thrown from
the trap. It's perfectly fine for the dead object proxy's preventExtensions
trap to throw an object is dead exception. In fact, that's precisely what
would happen if one
On 04/01/2013 09:41 AM, Brandon Benvie wrote:
That is, the error that will be thrown from Object.preventExtensions is only
specified as a TypeError; different engines can (and often do) have different
error messages, and different localizations will also have different
messages. This is
On 03/31/2013 11:02 AM, David Bruant wrote:
From the developer perspective, this doesn't really add anything since it's
already possible to throw from within the trap (and that's probably more
explicit and clearer than returning false).
That puts the onus on the trap to throw the correct
Negation on at least some x86-ish systems also produces another kind of NaN,
because the trivial negation implementation is a sign-bit flip.
This strikes me as similar to the endianness concerns of typed arrays, except
probably far less harmful in practice. I don't see what can reasonably be
On 03/03/2013 06:53 PM, Andrea Giammarchi wrote:
I had to check msdn rather than MDN since latter does not mention it while
mans shows an example:
http://msdn.microsoft.com/en-us/library/ie/3k9c4a32(v=vs.94).aspx
The RegExp statics aren't mentioned because they're a bad idea, imposing costs
On 03/03/2013 06:49 PM, Rick Waldron wrote:
Is this +1 to findIndex?
Not that I much care between the two, just making sure another reasonable name
is considered, but I'm not sure why it wouldn't be named find rather than
findIndex. The index seems like the only bit you'd reasonably be
On 03/04/2013 08:38 AM, Andrea Giammarchi wrote:
I believe creating a redundant array of matches for no reason since these are
retrievable in any case through the RegExp constructor, considering exec and
match points to those RegExp properties anyhow, ain't needed when
re.test(value) is
Consider:
Object.defineProperty(Object.prototype, 0, { value: 17, writable: false,
configurable: false });
[].push(42);
Per ES5, I think this is supposed to throw a TypeError. The push should be
setting property 0 with Throw = true, which means that when [[CanPut]] fails,
a TypeError
On 12/04/2012 03:57 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The timing of copying is only an issue if the function actually assigns to a
formal parameter. Such assignments should be pretty easy to
(conservatively) statically check for.
I'm telling you what engines do. Not what
implements.)
It looks like SpiderMonkey's Object.{seal,freeze,isSealed,isFrozen}
implementations do not call [[GetOwnProperty]] on each property. Cc'ing Jeff
Walden.
They do, sort of, but .caller doesn't fit into the [[GetOwnProperty]] system
well in SpiderMonkey because, on functions
On 11/16/2012 01:19 PM, Jeff Walden wrote:
and to defer all the strictness checks to when the function provided as
|this| is actually invoked.
Er, that should be and to have the 'caller' [[Get]] function check the
strictness of the |this| function provided to it when that [[Get]] function
On 11/16/2012 01:42 PM, Andrea Giammarchi wrote:
@Oliver, if you need to retrieve the caller in order to know if it's strict
or not, then everything I've read in this thread becomes kinda pointless :-(
Not quite. You could imagine a system where you simply have to know if your
caller is
On 11/16/2012 02:11 PM, Andrea Giammarchi wrote:
but I don't see caller being any better/worse than arguments and I believe
arguments will stick around forever in any case ... so will caller, unless
there's not some specific personal reason but the code just looks basically
the same: find
On 11/16/2012 02:37 PM, Andrea Giammarchi wrote:
what I am saying: arguments won't disappear in 5+ years, neither will caller
... is my crystal ball correct?
It's not necessary for these things to disappear completely for us to derive
value from these decisions. It's only necessary for good
On 10/26/2012 02:30 PM, David Bruant wrote: Le 26/10/2012 22:56, Asen Bozhilov
a écrit :
var obj = Object.defineProperty({}, '__proto__', {
get : function () {return '__proto__ getter'},
set : function (){return '__proto__ setter'}
});
console.log(obj.__proto__); //[object Object]
On 11/03/2012 11:06 PM, Mark S. Miller wrote:
On Sat, Nov 3, 2012 at 10:13 PM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de wrote:
(I am still sad we did not fix indexOf, lastIndexOf, and switch when we
arguably had the chance.)
Can you elaborate? We don’t have the
If __proto__ were a magical data property, what would happen if you did:
Object.defineProperty(Object.prototype, __proto__, { writable: false });
and then later:
({}).__proto__ = Object.prototype; // non-mutating mutation
or
({}).__proto__ = {}; // mutating mutation
or for that matter
On 07/17/2012 11:37 AM, Brendan Eich wrote:
I don't know what you mean by mutating mutation. In no case is the
non-writable magic property's internal setter called. Right?
According to the draft semantics, it seems no. Somehow I missed that semantics
had made their way into any draft, and I
In the [[SetP]] implementation on this page:
http://wiki.ecmascript.org/doku.php?id=harmony:proto_climbing_refactoring
In step 2, the property lookup should stop when a data descriptor of any sort,
writable or non-writable is uncovered. A property closer to the start of a
lookup shadows one
At least, if you consider |with| and |eval| fun (and who doesn't?):
js var x = outer; function f() { with({ x: 17 }) eval(var x); return x;
} typeof f()
undefined
This seems to be the behavior in every engine out there. But according to the last ES5
errata for 10.5, and in the latest ES6
On 01/28/2012 08:20 PM, felix wrote:
It seems to me the behavior you observe conforms to spec.
Hmm, yes, on second look I think you're right. I guess I was reading overfast
and missed the variable environment/lexical environment distinction there.
That, or it's been too long since I looked
On 11/15/2011 07:17 AM, Andy Wingo wrote:
SpiderMonkey appears to allow them, as does V8 with --harmony, but V8
without --harmony and JSC both abort on `const' in strict mode.
If you opt into a version supporting 'let', you get 'let' functionality. If
you don't, 'let' is a strict reserved
On 07/31/2011 03:57 AM, Andrea Giammarchi wrote:
I agree mine is more a workaround while we need a solution but it's not about Array here,
it's about number of arguments limit per function so once we have pushAll in place, all
other methods will still suffer the apply problem
True. It seems
On 07/29/2011 05:01 AM, Andrea Giammarchi wrote:
I may be late here, but what's wrong with
firstArray = firstArray.concat(secondArray); ?
If there are still problems I would say no magic method can solve them, isn't
it?
That creates a new array rather than mutate the array originally
On 07/29/2011 05:22 AM, Andrea Giammarchi wrote:
to avoid apply limits is actually trivial
More or less, yes.
But it requires the developer to anticipate the concern in advance that the
elements being appended might consume all available stack space. I don't think
most developers think at
On 07/27/2011 10:12 PM, Mark S. Miller wrote:
We could debate the pros and cons of this sort of chaining convention in
general. However, in this case I think the more important issue is API
consistency.
I was thinking this might actually be more consistent, to return this.
Consider
On 07/27/2011 01:26 PM, John-David Dalton wrote:
@Jeff In reply to
https://mail.mozilla.org/pipermail/es-discuss/2011-July/016124.html,
which engines have problems with `firstArray.push.apply(firstArray,
secondArray)` ?
Shouldn't a bug report be filed for the specific JS engine or the spec
be
If I have one array, and I want to append the contents of an arbitrary array to
it, and I don't need the unmodified first array after appending the second
array's elements to it, I have three options.
First, I can use Array.prototype.concat to create a new array consisting of the
first array,
It's perhaps worth noting that this problem also occurs with
String.fromCharCode. I suspect the need for a version of
|String.fromCharCode.apply(null, codesArray)| that always works, even for
super-big |codesArray|, is rather smaller than for the similar
Array.prototype.push concern.
Jeff
On 07/22/2011 03:16 PM, Mike Shaver wrote:
Which primitives have own properties? I thought even str.length conceptually
came from the prototype.
Spec-wise, it comes from the boxed String object created when you attempt to look up a
property on a primitive string. It's the same for str[0]
On 07/22/2011 04:13 PM, Axel Rauschmayer wrote:
In strict-mode, this isn’t boxed in, say, String.prototype.* methods. But I
don’t know how/whether that reflects the spec.
This is not quite precisely true. See the second algorithm in 8.7 GetValue(V).
If you implement exactly the steps in
On 07/14/2011 10:04 AM, Allen Wirfs-Brock wrote:
It is probably a bug, because array index based operations generally warp
around to 0 at 2^32.
Freudian slip? :-D
Easiest fix is to just add the length-set to concat. For a quick ES5 erratum
that seems best to me.
Removing all the
Reraising this issue...
To briefly repeat: Decode, called by decodeURI{,Component}, says to reject %ab%cd%ef sequences whose octets
[do] not contain a valid UTF-8 encoding of a Unicode code point. It appears browsers interpret
this requirement as: reject overlong UTF-8 sequences, and
On 05/17/2011 09:49 PM, Luke Hoban wrote:
It seems the syntax is perhaps aiming to avoid needing to allocate an
intermediate object – but I imagine engines could potentially do that for
Object.make and friends as well if it was important for performance?
It's probably possible to do that.
This is an interesting idea, never heard of it before. That said, it seems a
better start for brainstorming than as an end of it. The previously-mentioned
concerns about numbering being fragile seem real to me. Further, how would
this interact with eval introducing (or in some systems even
On 03/26/2011 07:44 PM, Brendan Eich wrote:
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an outer
function, the return is legal).
I might be
I think you've rediscovered the bug mentioned in the list thread titled Assigning
to eval-introduced local bindings outside strict mode, and an ES5 spec bug,
spanning 20101124-20101126. I don't know whether any followup happened to fix that or
not in the spec, haven't been concerned enough to
On 03/12/2011 12:02 AM, Brendan Eich wrote:
Take it from me, JS objects are not hashmaps and any would-be implementor who
tries that and tests on real code is quickly disabused of the notion. It's not
going to change, for named properties or any kind of property name.
This is true.
It is
On 03/11/2011 02:07 PM, Charles Kendrick wrote:
Your perspective is common in a group like this - very spec and standard
focused. Isn't it fun to bash those developers? Everyone's doing it.. I hope
you realize it's irrelevant though?
Insinuating bad faith (Isn't it fun and Everyone's doing
Another idea might be to introduce OrderedObject or somesuch with guaranteed
enumeration order. You might lose object literal support (although that could
be readded), but that's the only loss that comes to mind after brief thought.
Jeff
___
On 03/10/2011 06:11 PM, Boris Zbarsky wrote:
You may want to read https://bugzilla.mozilla.org/show_bug.cgi?id=594655 and
https://bugzilla.mozilla.org/show_bug.cgi?id=611423. People are running into
performance issues due to lack of such special treatment today.
Further to these points, it
A few months back I noticed an interesting interaction between how direct eval
is defined and multiple globals. What happens if, in one global, you call an
eval from another global as if it were a direct eval?
var indirect = otherGlobal.eval;
eval = indirect;
print(eval(this) === this);
On 03/03/2011 04:41 PM, Allen Wirfs-Brock wrote:
I think your real question reduces to this:
//none strict mode code
globalObj= function() {return this}();
print(otherGlobal.eval(this) === globalObj) //??
The two different calls and the indirect name in your example may make the
question
On 02/16/2011 05:32 PM, Irakli Gozalishvili wrote:
I was under the impression that inherited properties can be overridden,
regardless of their write-ability on the __proto__.
Here's another take on this -- same idea, just another statement of it.
You can override any inherited property. You
On 01/09/2011 06:02 AM, Jorge wrote:
Or perhaps to overload * ?
'a' * 5
- a
?
Probably a bridge too far. Operator overloading this way results in all those
weird implicit conversion behaviors we all know and love (not), true. But at
this point there's the matter of compatibility:
Check out the ES5 erratum -- steps 5 and 7 have been removed.
http://wiki.ecmascript.org/doku.php
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 10/27/2010 07:24 PM, Michael Dyck wrote:
If I find bugs in the ECMAScript Language spec (bugs that aren't already
reflected in the July 31st Errata doc), what should I do?
Post 'em here, that's what everyone else has done.
Jeff
___
es-discuss
On 10/14/2010 08:29 AM, Brendan Eich wrote:
Thus there is already one bit of opt-in versioning state in ES5, which must be
carried from direct eval's caller to callee.
SpiderMonkey currently does this, but fairly shortly (I have patches) it will
not. The eval *function*'s implementation
On 08/29/2010 03:28 PM, Douglas Crockford wrote:
For what it's worth, JSLint does not tolerate any whitespace between . and a
property name.
Tangential, but does JSLint then require either long sequences of property accesses and
method calls to occur all on a single line or to always be
On 10/13/2009 10:54 PM, Luke Smith wrote:
Currently FF3.5.4 doesn't properly apply replacer functions, but Safari
4, WebKit, IE8, and Chrome 3 work fine for this task.
How precisely are replacer functions not properly applied in Firefox? I
remember reporting at least one bug on the
If Octects does not contain a valid UTF-8 encoding of a Unicode code point throw a
URIError exception.
s/Octects/Octets/
Maybe too late for ES5 (except in errata?), but certainly for ES6.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
I was looking at how SpiderMonkey decodes URI-encoded strings, specifically to update it to reject
overlong UTF-8 sequences per ES5 (breaking change from ES3 that should generally be agreed to have
been necessary, not to mention that existing implementations were loose and strict
17. Call the [[DefineOwnProperty]] internal method of A with arguments
length, Property Descriptor
{[[Value]]: n + 1, [[Writable]: true, [[Enumerable]]: true, [[Configurable]]:
true}, and true.
This is attempting to define an enumerable, configurable length property on an
array, which will
On 17.9.09 12:15 , Jason Orendorff wrote:
The difference shows up in step 7b, whose wording is:
Reject, if the [[Enumerable]] fields of current and Desc are the Boolean
negation of each other.
Under the first interpretation, if there is no [[Enumerable]] field in Desc,
then never Reject.
On 13.9.09 11:56 , Olav Kjær wrote:
While experimenting with code-completion for ECMAScript I noticed a
limitation with array comprehension syntax.
The syntax as proposed (and implemented in Mozilla) has the output
expression before the loop and filter:
[i.toString() for each (i in
If a field is absent then the result of any test of its value is logically
false.
I believe there are two plausible ways to interpret this: any evaluation of
desc.[[Something]] when there is no [[Something]] field returns the value
false, or the result of any comparison which evaluates
The steps are numbered 1-8, but 5-7 are clearly intended to be a substep of 4.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
http://es5conform.codeplex.com/sourcecontrol/changeset/view/55693?projectName=ES5conform#816017
A number of tests include comments noting that the test function must be
executed such that this is the global object. As the harness is currently
implemented, this isn't the case -- this is the
to an accessor property with the attribute value {[[Put]]:undefined}
s/Put/Set/
(I'm guessing the setter field used to be [[Put]] until someone realized how
awesomely confusing it would be for both objects and property descriptors to
have a field with the same name, one of which might call
On 4.9.09 03:02 , Jeff Walden wrote:
to an accessor property with the attribute value {[[Put]]:undefined}
s/Put/Set/
Also in the note in 11.13.1.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES3, 15.3.5.2, says the prototype property of function instances is enumerable.
ES5, 13.2 step 17, says the prototype property of function instances is not
enumerable.
Was this change intentional, and if so, can someone point me to discussion of
the change? I don't care one way or the other,
On 22.8.09 14:00 , Allen Wirfs-Brock wrote:
15.2.3.7 Object.defineProperties “atomic†processing clarified.
This still needs further clarification on how to address definition of properties on
objects with custom [[DefineOwnProperty]] hooks, as earlier alluded to by David-Sarah
Hopwood.
On 12.8.09 14:33 , Allen Wirfs-Brock wrote:
ES5 section 12.6 (for-in statement) says:
That's specifically for the for-in statement in the language, not for a term of
art used in other locations in the specification. If we want to adopt the
definition, I think this should either be noted in
1 - 100 of 106 matches
Mail list logo
