Re: How can GetModuleNamespace throw a SyntaxError?
> Jon: yes, it might be a redundant error, I will investigate more. > > /caridy Module Records other than Source Text Module Records could return `null` when calling ResolveExport() in GetModuleNamespace(). The specification of the abstract ResolveExport() method does not forbid this case. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Assignment of global variables deleted by their RHS in strict mode
A fix for this would be in 8.1.1.4.5, insert between the current steps 4 and
5:
4.5 If S is true, then
a. Let stillHasBinding be ObjRec.HasBinding(N).
b. ReturnIfAbrupt(stillHasBinding).
c. If stillHasBinding is false, throw a ReferenceError exception.
I think the check should go into 8.1.1.2.5 SetMutableBinding. That way the
similar issue for object
environment records gets also fixed:
```
var scope = {x: 1};
with (scope) {
(function() {
use strict;
x = (delete scope.x, 2);
})();
}
```
Except for SpiderMonkey, all other engines tested (Edge, Nashorn, JSC, V8)
already throw a
ReferenceError for the above snippet. But that's probably because engines don't
implement the
'correct' Reference type semantics
(https://bugs.ecmascript.org/show_bug.cgi?id=4379).
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: let function
On May 14, 2015, at 12:40 PM, Alexander Jones wrote: Ah, thanks for explaining! What about the Temporal Dead Zone of let, or const binding semantics, for those of us who are obsessive enough to desire that kind of thing everywhere? ES6 specifies that function declarations are allowed in blocks in both strict and nn-strict mode. In both cases they are block scoped and have essentially the same semantics (including a TDZ) as a let declaration. There is no TDZ for block-scoped function declarations. Function declarations are basically hoisted to the top of the block. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: What is `this` inside a new-invoked generator?
Question: what does the following code snippet log in the last line?
```js
function* gen() {
yield this;
}
let genObj = new gen();
let [_this] = genObj;
console.log(_this === genObj); // ???
```
I’m finding three answers:
1. The spec says [1] that any reference to `this` in a generator invoked via
`new` causes a `ReferenceError`.
2. Firefox logs `false` for the code snippet.
3. A year ago, Allen stated [2] that if you invoke a generator function via
`new`, `this` points to the generator object. On other words, the code snippet
would log `true`.
It's a ReferenceError. Future editions may add a meta property to make it possible to retrieve the
current generator object (https://bugs.ecmascript.org/show_bug.cgi?id=3626).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module import/export bindings
From my current understanding (based on other threads), this module:
```js
var foo = 42;
export default foo;
export foo;
foo = 10;
I guess you'd intended to write `export {foo as default}` instead of `export default foo`, because
the latter exports the value of the expression when it gets evaluated. IOW it's the same as `export
default 42`.
However, I am curious if this binding is 2-way or only 1-way. What happens if I
do:
```js
import foo, * as FOO from coolmodule;
foo = 100;
FOO.default = 200;
FOO.foo = 300;
All three assignments throw a TypeError exception:
- The first assignment throws a TypeError in 8.1.1.1.5 SetMutableBinding, step 6. (Import bindings
are immutable - 8.1.1.5.5 CreateImportBinding, step 5.)
- The second and third assignment throw a TypeError in 6.2.3.2 PutValue, step 6.d. (Module namespace
objects always return false from [[Set]] - 9.4.6.9 [[Set]].)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Q: Lonely surrogates and unicode regexps
On 1/28/2015 2:51 PM, André Bargull wrote: For a reference, here's how Java (tried w/ Oracle 1.8.0_31 and openjdk 1.7.0_65) Pattern.UNICODE_CHARACTER_CLASS works: foo\uD834bar and foo\uDC00bar match ^foo[^a]bar$ and ^foo.bar$, so, generally, lonely surrogates match /./. Backreferences are allowed to consume the leading surrogate of a valid surrogate pair: Ex1: foo\uD834bar\uD834\uDC00 matches foo(.+)bar\1 But surprisingly: Ex2: \uDC00foobar\uD834\uDC00foobar\uD834 doesn't match ^(.+)\1$ ... So Ex2 works as if the input string was converted to UTF-32 before matching, but Ex1 works as if it was def not. Idk what's the correct mental model where both Ex1 and Ex2 would make sense. java.util.regex.Pattern matches back references by comparing (Java) chars [1], but reads patterns as a sequence of code points [2]. That should help to explain the differences between ex1 and ex2. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l4890 [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l1671 Err, the part about how patterns are read is not important here. What I should have written is that the input string is (also) read as a sequence of code points [3]. So in ex2 `\uD834\uDC00` is read as a single code point (and not split into \uD834 and \uDC00 during backtracking). [3] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l3773 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Q: Lonely surrogates and unicode regexps
For a reference, here's how Java (tried w/ Oracle 1.8.0_31 and openjdk 1.7.0_65) Pattern.UNICODE_CHARACTER_CLASS works: foo\uD834bar and foo\uDC00bar match ^foo[^a]bar$ and ^foo.bar$, so, generally, lonely surrogates match /./. Backreferences are allowed to consume the leading surrogate of a valid surrogate pair: Ex1: foo\uD834bar\uD834\uDC00 matches foo(.+)bar\1 But surprisingly: Ex2: \uDC00foobar\uD834\uDC00foobar\uD834 doesn't match ^(.+)\1$ ... So Ex2 works as if the input string was converted to UTF-32 before matching, but Ex1 works as if it was def not. Idk what's the correct mental model where both Ex1 and Ex2 would make sense. java.util.regex.Pattern matches back references by comparing (Java) chars [1], but reads patterns as a sequence of code points [2]. That should help to explain the differences between ex1 and ex2. [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l4890 [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l1671 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Q: Lonely surrogates and unicode regexps
On Wed, Jan 28, 2015 at 11:36 AM, Marja Hölttä marja at chromium.org https://mail.mozilla.org/listinfo/es-discuss wrote: / The ES6 unicode regexp spec is not very clear regarding what should happen // if the regexp or the matched string contains lonely surrogates (a lead // surrogate without a trail, or a trail without a lead). For example, for the // . operator, the relevant parts of the spec speak about characters: // / Just a bit of terminology. The term character is overloaded, so Unicode provides the unambiguous term code point. For example, U+0378 is not (currently) an encoded character according to Unicode, but it would certainly be a terrible idea to disregard it, or not match it. It is a reserved code point that may be assigned as an encoded character in the future. So both U+D83D and U+0378 are not characters. If a ES spec uses the term character instead of code point, then at some point in the text it needs to disambiguate what is meant. character is defined in 21.2.2 Pattern Semantics [1]: In the context of describing the behaviour of a BMP pattern “character” means a single 16-bit Unicode BMP code point. In the context of describing the behaviour of a Unicode pattern “character” means a UTF-16 encoded code point. [1] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-pattern-semantics ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Q: Lonely surrogates and unicode regexps
On 1/28/2015 3:36 PM, Marja Hölttä wrote:
Based on Ex1, looks like the input string is not read as a sequence of code
points when we try to
find a match for \1. So it's mostly read as a sequence of code points except
when it's not. :/
Yep, back references are matched as a sequence of code units. The first link I've posted points to
the relevant method in java.util.regex.Pattern. I've got no idea why it's implemented that way, for
example when you enable case-insensitive matching, back references are no longer matched as a
sequence of code units:
---
int[] flags = { 0, Pattern.CASE_INSENSITIVE, Pattern.UNICODE_CASE,
Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE };
// Prints true, false, true, false
Arrays.stream(flags).mapToObj(f - Pattern.compile(foo(.+)bar\\1, f))
.map(p - p.matcher(foo\uD834bar\uD834\uDC00).find())
.forEach(System.out::println);
---
On Wed, Jan 28, 2015 at 3:11 PM, André Bargull andre.barg...@udo.edu
mailto:andre.barg...@udo.edu wrote:
On 1/28/2015 2:51 PM, André Bargull wrote:
For a reference, here's how Java (tried w/ Oracle 1.8.0_31 and
openjdk
1.7.0_65) Pattern.UNICODE_CHARACTER___CLASS works:
foo\uD834bar and foo\uDC00bar match ^foo[^a]bar$ and ^foo.bar$, so,
generally, lonely surrogates match /./.
Backreferences are allowed to consume the leading surrogate of a
valid
surrogate pair:
Ex1: foo\uD834bar\uD834\uDC00 matches foo(.+)bar\1
But surprisingly:
Ex2: \uDC00foobar\uD834\__uDC00foobar\uD834 doesn't match ^(.+)\1$
... So Ex2 works as if the input string was converted to UTF-32
before
matching, but Ex1 works as if it was def not. Idk what's the
correct mental
model where both Ex1 and Ex2 would make sense.
java.util.regex.Pattern matches back references by comparing (Java)
chars [1], but reads
patterns as a sequence of code points [2]. That should help to explain
the differences
between ex1 and ex2.
[1]
http://hg.openjdk.java.net/__jdk8u/jdk8u/jdk/file/__c46daef6edb5/src/share/__classes/java/util/regex/__Pattern.java#l4890
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l4890
[2]
http://hg.openjdk.java.net/__jdk8u/jdk8u/jdk/file/__c46daef6edb5/src/share/__classes/java/util/regex/__Pattern.java#l1671
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l1671
Err, the part about how patterns are read is not important here. What I
should have written is
that the input string is (also) read as a sequence of code points [3]. So
in ex2 `\uD834\uDC00`
is read as a single code point (and not split into \uD834 and \uDC00 during
backtracking).
[3]
http://hg.openjdk.java.net/__jdk8u/jdk8u/jdk/file/__c46daef6edb5/src/share/__classes/java/util/regex/__Pattern.java#l3773
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c46daef6edb5/src/share/classes/java/util/regex/Pattern.java#l3773
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Q: Lonely surrogates and unicode regexps
Cool, thanks for clarifications! To make sure, as per the intended semantics, we never allow splitting a valid surrogate pair (= matching only one of the surrogates but not the other), and thus we'll differ from the Java implementation here: /foo(.+)bar\1/u.test(foo\uD834bar\uD834\uDC00); we say false, Java says true. Correct, the captures List entry is [\uD834], so when performing 21.2.2.9 AtomEscape, \uD834 is matched against \uD834\uDC00 in step 8 which results in a failure state. (In addition, /^(.+)\1$/u.test(\uDC00foobar\uD834\uDC00foobar\uD834) == false.) Yes, this expression also returns false. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Very large array indices and unshift/splice
On 10/27/2014 5:09 PM, Allen Wirfs-Brock wrote:
On Oct 26, 2014, at 8:58 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Arguably a design bug, rather than a spec. bug. But I'm assuming that who ever
originally wrote up these algorithms were being intentional about such things.
Design, vs. accidental. Spec, vs. implementation. Potato, Potahtoe :-P.
I think we should fix 'em as we find them, if implementations do not agree (and
they don't usefully agree here).
I probably wasn't clear about the central issue:
unshift and other array methods are generic methods that work the same on any object that
has a 'length' property and array index properties. When implemented as
currently specified they produce consistent predictable results across for any such
object, even if specified error conditions occur.
There are many ways that a particular kind of array-like object can constrain
their 'length' property. There could be limits built into [[Get]]/[[Set]] (this is how
exotic Arrays work), or the 'length' property might be readonly, or the 'length' property
might be an accessor property that constrains the length value algorithmically, or the
object might be a Proxy whose handler does whatever.
Given all of these alternatives, we currently don't have any single generic way
to predetermine if 'length' extending operations such as unshift/splice will
run into 'length' restrictions in the course of executing their generic
algorithm. We might invent such a thing (perhaps a @@maxLength property). But
that isn't a bug fix, that is a significant design change.
Allen
Somewhat related: Does it make sense to check if the length will exceed the 2^53-1 limit? And is
ToString(9007199254740993) properly defined, where 9007199254740993 is a mathematical real number as
defined in 5.2 Algorithm Conventions. As I understand it, ToString (7.1.12) is not defined for
arbitrary numbers, but only for the Number type (6.1.6 The Number Type).
A simple example where this issue arises:
---
var a = {length: Math.pow(2,53)-1};
Array.prototype.push.call(a, ...abc);
print(a[9007199254740991]); // ?
print(a[9007199254740992]); // ?
print(a[9007199254740993]); // ?
---
Thanks,
André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Very large array indices and unshift/splice
Unlikely, given what Adam reported: V8 properly throws a range error, but fails to move the element up one index. SpiderMonkey hangs (presumably because it has no special logic to deal with very large, sparse arrays). JSC throws an Out of memory Error and also fails to move the element up one index. Anyone care to test IE? IE11 moves elements up one index, throws a RangeError and completes instantly (no hang or oom). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for-of loops, IteratorClose and the rest of the iterations in the spec
/ Seems to me like it's just a matter of wrapping the relevant bits (which
ones, though?
// whatever constitutes the loop body
//
// OK. That's fairly straightforward.
//
// You also will need a finally clause, if the loop body contains any explicit returns.
//
// It only does when the iterator claims there are no more things to be had, in which case do I still want to be calling the return() thing?
/
No, you only call 'return' when exiting the loop before the iterator has
indicated that it is 'done'..
Just for the sake of completeness, here is complete translation of
`for-of` to ES5 syntax.
ES6 for-of statement:
---
for (var value of iterable) {
if (doReturn) return;
if (doBreak) break;
if (doContinue) continue;
otherExpression;
}
---
Translated to ES5 syntax:
---
var $iterable = iterable;
if ($iterable === undefined || $iterable === null) {
throw new TypeError();
}
var $iterator = Object($iterable)[Symbol.iterator]();
if (Object($iterator) !== $iterator) {
throw new TypeError();
}
while (true) {
var $nextResult = $iterator.next();
if (Object($nextResult) !== $nextResult) {
throw new TypeError();
}
if ($nextResult.done) {
break;
}
var $nextValue = $nextResult.value;
var $callClose = false;
try {
value = $nextValue;
if (doReturn) { $callClose = true; return; }
if (doBreak) { $callClose = true; break; }
if (doContinue) continue;
otherExpression;
} catch ($exception) {
try {
if (return in $iterator) {
$iterator.return();
}
} catch ($ignore) {
// ignore
}
throw $exception;
} finally {
if ($callClose) {
if (return in $iterator) {
$iterator.return();
}
}
}
}
---
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Question about GetBindingValue
Hello,
We found one dead part in ES5 and we're wondering whether we're missing
something here. The question is about the 4th step in Section 10.2.1.2.4
GetBindingValue(N, S):
10.2.1.2.4 GetBindingValue(N,S)
The concrete Environment Record method GetBindingValue for object environment
records returns the value of its associated binding object's property whose
name is the String value of the argument identifier N. The property should
already exist but if it does not the result depends upon the value of the S
argument:
1. Let envRec be the object environment record for which the method was
invoked.
2. Let bindings be the binding object for envRec.
3. Let value be the result of calling the [[HasProperty]] internal method of
bindings, passing N as the property name.
4. If value is false, then
a. If S is false, return the value undefined, otherwise throw a
ReferenceError exception.
5. Return the result of calling the [[Get]] internal method of bindings,
passing N for the argument.
We believe that the 4th step is unreachable. In other words, whenever
GetBindingValue(N, S) is called, the result of calling the [[HasProperty]](N)
is always true and here's why:
Yes, that reasoning looks correct.
10.2.1.1.4 may have a similar problem but we haven't checked it yet.
The only immutable bindings present in ES5 are directly initialized
before user code can be executed, so yes, step 3 in 10.2.1.1.4 is never
reachable in ES5.
We checked with the recent ES6 draft but it seems to have the same issue.
In ES6 it's actually possible to reach that step (8.1.1.2.6
GetBindingValue, step 5), albeit it's a somewhat tricky and involves
doing unusual things with proxy objects:
```javascript
with(new Proxy({}, {
has: function(t, name) {
print(has: +name);
return !this.called (this.called = true);
}})) {
(function(){ use strict; ref })();
}
```
That program will give the following output:
---
has: ref
has: ref
uncaught exception: ReferenceError: cannot resolve reference: ref
---
Proxy objects allow you to define your own [[HasProperty]]
implementation (the has method in the example above). In this case
[[HasProperty]] will return `true` on the first call in order to report
a binding is present in HasBinding, but then will return `false` when
the binding's presence is checked the second time in GetBindingValue.
Best,
--
Sukyoung
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String(symbol)
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 correct-and-most-concise way to do it. It should throw on symbols, that's important. Having String(sym) not throw is a win for other reasons Arv identified, but using String(any) to invoke ToString is verbose and fragile, because String could be rebound :-P. Use +'' if you want ToString in the language, I say. /be If `x` is an object, x + '' performs ToString(ToPrimitive(x, no hint)), whereas String(x) performs ToString(ToPrimitive(x, hint String)). So both expressions are not always interchangeable. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why are Symbol.* all non-configurable and non-writable?
Because somebody thought it was a good idea ;-) ... I'd say for consistency with other constant value properties (NaN, Infinity, undefined, Math.*, Number.*). On Jul 21, 2014, at 1:04 PM, Boris Zbarsky wrote: / Is this meant to prevent people tampering with them? // // In that case, global.Symbol should also be non-configurable non-writable or something. Otherwise you can just redefine it. / You're probably right that locking down one doesn't make all that much sense without locking down the other. We have a history of not make global object properties readonly/non-configurable. There also may be configurability issues for dynamically created Realms that we'd want to think about before making Symbol readonly/non-writable. Probably with some more discussion. Allen - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 classes: deferring the creation step
Moreover, the Completion record (either normal or abrupt) returned from [[Call]] will hold an additional [[thisValue]] field, which, unless otherwise specified: * is set to the original `thisArgument` if it was not empty; or, * is set to the value (at the time of completion) of the this-binding, if it was initially uninitialised but has been initialised; or, * is absent if the this-binding was left uninitialised. Hmm, mixed feelings about extending the Completion record type to hold another field. It could be problematic for implementors to store this additional state efficiently. On second thought, it should be possible to merge [[thisValue]] with the existing [[Value]] field, and conditionally handle [[Value]] == empty in [[Construct]]? [1] Moreover, the Completion record (either normal or abrupt) returned from [[Call]] will hold an additional [[thisValue]] field, which, unless otherwise specified: * is set to the original `thisArgument` if it was not empty; or, * is set to the value (at the time of completion) of the this-binding, if it was initially uninitialised but has been initialised; or, * is absent if the this-binding was left uninitialised. Tail-call semantics may interfere with determining the value of this-binding at the time of completion, because the execution context was already popped from the stack at that time. Probably solvable by determining the this-binding before performing the tail-call, plus some special casing when the tail-call expression is a super-call. When, say, `super.method(..args)` is called, the following steps are taken: 1. Let `F` be the method referenced by `super.method`. This part needs to be redefined. `super.method` is an abbreviation for: 1. Let env be GetThisEnvironment(). 2. Let baseValue be GetSuperBase(env). 3. Let actualThis be GetThisBinding(). 4. Let result be baseValue.[[Get]](method, actualThis). But at `this`-binding initialisation time, `actualThis` is still the empty placeholder object, so it cannot be used as the receiver argument for the [[Get]] internal method call. [1] https://gist.github.com/anba/e6b525c124d09dafaed6 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@new
The most important thing here (I agree with Andreas R.) is -- if possible -- avoiding uninitialized object observability. I agree that uninitialized observability is a pain and has been a on-going source of reentrancy bugs in the the more complex built-in constructors. I want to explore whether making the constructor arguments available to @@create provides an alternative way to eliminate that issue. That means depending on the class/built-in a subclass needs to override either the @@create method or the constructor function or both? For example let's take the Map built-in. The @@create method will initialise [[MapData]] to an empty list early on, that way Map instances are never observed uninitialised. Processing the iterable argument to fill the Map may either occur in @@create or in the Map constructor function. Subclasses will need to consult the specification to find out which method needs to be overridden if the iterable argument needs to be preprocessed. For other (more special) built-ins like String/Number/Function/..., @@create will need to perform the complete initialisation including processing the arguments. Otherwise uninitialised objects are still observable. As a result subclasses are required to override @@create and overriding the constructor is a no-op (w.r.t. arguments handling). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
One question about @@create though... What would this do:
function Foo () {}
Foo.prototype[Symbol.create] = null;
// ???
// Maybe error out, like currently host objects without [[Construct]]:
// TypeError: Foo is not a constructor.
new Foo();
- Jussi
```javascript
function Foo(){}
Object.defineProperty(Foo, Symbol.create, {value: null});
new Foo();
```
Results in `uncaught exception: TypeError: Symbol(Symbol.create) is
not a function`.
Whereas this version creates a default object with [[Prototype]] set to
`Bar.prototype`:
```javascript
function Bar(){}
Object.defineProperty(Bar, Symbol.create, {value: void 0});
new Bar();
```
The exact behaviour is specified in CreateFromConstructor(F) and
Construct(F, argumentsList)
-
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createfromconstructor
-
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-construct-f-argumentslist
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 6 June 2014 TC39 Meeting Notes
Thanks for the notes, Ben! Looks like a real slog but it's much appreciated. On Wed 11 Jun 2014 18:28, Ben Newman benjamin at cs.stanford.edu https://mail.mozilla.org/listinfo/es-discuss writes: / ## Async Generator Functions (Jafar presenting) // (Jafar to send slides) / Looking forward to seeing these slides. Andy I don't know if these slides are the final version which was presented at the meeting: https://docs.google.com/a/netflix.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU And related: https://github.com/jhusain/asyncgenerator - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
I'd be most interested in seeing if we can remove IsConstructor entirely (except for uses where it's just a guard, implementing the semantics of `new` via IsConstructor - [[Construct]] or throw). It seems like there's at least some movement toward removing it from `Array.of` and `Array.from`. All that remains is its use to preserve the `arrayInstance.constructor = undefined` backward-compatibility possibilities. My preference would be to see if we can get away with breaking that use case, and reintroduce it if that turns out not to be web-compatible. The [[Realm]] check in Array.prototype.* is even more annoying than the IsConstructor guard, but unfortunately required for web-compatibility per [1]. :-( [1] http://esdiscuss.org/topic/array-prototype-slice-web-compat-issue ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote: / While working on changing Date.prototype to be a plain object in SpiderMonkey, we realized that there's an issue: the way things are specced now, `alert(Date.prototype)` will throw, because `Date.prototype.toString` isn't generic. The same applies for all builtins with non-generic `toString` prototype functions. / Fortunately there aren't very many of those. I think it is only Date and RegExp that have this issue among the ES6 built-ins And Number.prototype, String.prototype, Boolean.prototype and Symbol.prototype. And actually it's even worse for Symbol.prototype because of the @@toPrimitive override. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
/ Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
//
// The following test passes using the spec algorithms:
//
// var c = 0;
// for (var x of null) {
//c++;
// }
// assert.equal(c, 0);
//
// However, if we get a null value here we are most likely just masking an user bug.
//
// I assume the justification is that for-in allows null here? However, for-of is new syntax and we have the chance to get this right this time around.
/
Yup, there was an issue that was reported and fixed fairly recently pointing
out that for-of was inconsistent with for-in in this respect.
for-of statement iteration always ignored undefined/null (always = since
it was added in rev6). I've only requested in [1] to align for-of
iteration in statements and comprehensions to have the same behaviour
w.r.t. undefined/null.
[1] https://bugs.ecmascript.org/show_bug.cgi?id=273
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
Corrected link: https://bugs.ecmascript.org/show_bug.cgi?id=2737
On 6/13/2014 12:16 AM, André Bargull wrote:
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
/ Somehow I missed when we decided to allow null/undefined as the iterable
value in for-of loops.
//
// The following test passes using the spec algorithms:
//
// var c = 0;
// for (var x of null) {
//c++;
// }
// assert.equal(c, 0);
//
// However, if we get a null value here we are most likely just masking an user bug.
//
// I assume the justification is that for-in allows null here? However, for-of is new syntax and we have the chance to get this right this time around.
/
Yup, there was an issue that was reported and fixed fairly recently pointing
out that for-of was inconsistent with for-in in this respect.
for-of statement iteration always ignored undefined/null (always =
since it was added in rev6). I've only requested in [1] to align
for-of iteration in statements and comprehensions to have the same
behaviour w.r.t. undefined/null.
[1] https://bugs.ecmascript.org/show_bug.cgi?id=273
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the IsConstructor will always return true which is really not what you want. If IsConstructor was changed to check for a .prototype instead proxies would behave more inline with ordinary objects. [[Construct]] is only attached to a proxy if the target has a [[Construct]] internal method. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just
need to wait until Proxies are available everywhere! ;-)
On Wed, Jun 11, 2014 at 10:58 AM, Rick Waldron waldron.rick at gmail.com
https://mail.mozilla.org/listinfo/es-discuss
wrote:
/
//
//
// On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
// domenic at domenicdenicola.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
//
// A variety of places in the spec use the new IsConstructor abstract
// operation. In ES5, this test (essentially, does the object implement the
// [[Construct]] internal method) was restricted to the `new` operator. But
// in ES6, it is used in implementing a large variety of built-in functions:
//
// - All Array methods
// - All %TypedArray% methods
// - All Promise methods (via NewPromiseCapability)
//
// (Note that there are two uses: arrays and typed arrays do alternative
// logic for non-constructors; promises fail immediately. This inconsistency
// might be a bug?)
//
// It seems to me that we should expose this primitive reflective operation
// to users, instead of having all of these methods be able to detect
// something that user code can't, and thus making them harder to explain or
// polyfill.
//
//
// Alternately, if we don't think users should be doing this kind of
// reflection, then we probably shouldn't be doing it ourselves. In which
// case, figuring out an alternate path for the above methods would be
// useful---perhaps they simply try to construct, and fail immediately if
used
// with a non-constructible object, instead of falling back.
//
//
// I had similar questions a couple years ago and Allen advised that the
// easiest polyfill for such a mechanism is:
//
// function isConstructor(C) {
//try {
// new C();
// return true;
//} catch (e) {
// return false;
//}
// }
//
//
// Additionally, at the July 2012 tc39 meeting I proposed (over breakfast) an
// ES7 standard library module that exported the abstract operations that
// are now defined in chapter 7
// http://people.mozilla.org/~jorendorff/es6-draft.html#sec-abstract-operations,
http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-abstract-operations,
// the response was positive but it was far too early to have a serious
// discussion. Anyway, with that you'd just write:
//
// import { isConstructor } from es-abstract;
//
//
// Rick
//
/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: IsConstructor
On 6/11/2014 5:40 PM, Alexandre Morgaut wrote:
On 11 juin 2014, at 17:11, André Bargull andre.barg...@udo.edu wrote:
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just need to
wait until Proxies are available everywhere! ;-)
Not sure Proxy solve anything when we want to test the constructor nature of a
function and be sure invoking it won't change anything in the current
application context
To highlight what side-effects mentioned by Rick could be, a tested function
while invoked may:
- do DOM Manipulations,
- change properties in the global object,
- initiate Web Sockets or Web Workers...
Not safe at all...
From [1]:
```javascript
function IsConstructor(o) {
try {
new (new Proxy(o, {construct: () = ({})}));
return true;
} catch(e) {
return false;
}
}
```
This IsConstructor implementation does not trigger any side-effects and
works even when the underlying constructor requires arguments etc.
[1]
https://github.com/anba/es6draft/blob/master/src/test/scripts/suite/lib/assert.js#L53-L60
[...]
Alexandre Morgaut
Wakanda Community Manager
4D SAS
60, rue d'Alsace
92110 Clichy
France
Standard : +33 1 40 87 92 00
Email :alexandre.morg...@4d.com
Web : www.4D.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
that `has:()=true` breaks with features detections that are meant to be less obtrusive than getters ... i.e. `'geolocation' in navigator` or `'innerHTML' in genericNode` and all others that are not supposed to pass through a potentially expensive getter to retrieve a feature detection purpose info. Long story short that NoSuchProperty is obtrusive in an upside-down way ... I personally would not use that and would not expect that anywhere The 'has' handler is required to work around a Firefox limitation. A compliant ES6 implementation only needs the 'get' handler. Related bug reports: https://bugzilla.mozilla.org/show_bug.cgi?id=914314 https://bugzilla.mozilla.org/show_bug.cgi?id=1009199 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations
Or a link to the discussion that led to the content of this section? There have been multiple discussions on this topic, on both es-discuss and during TC39 meetings, so it's hard to point to a single discussion. For example: http://esdiscuss.org/topic/real-world-func-decl-in-block-scope-breakages http://esdiscuss.org/topic/functions-as-blocks https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-29.md#function-in-blocks-in-non-strict-mode On Thu, Jun 5, 2014 at 9:51 AM, John Lenz concavelenz at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: / Is there any place that has some concrete examples of the different cases // we are trying support with this section (and whether the function is block // scoped or not in each case)?/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Assignment to wrapper objects in strict mode
Apparently, there has been a semantic change between ES5 and ES6 regarding assignment to wrapper objects in strict mode. That is, 'use strict'; .x = 0 would throw in ES5, but AFAICS, no longer does in ES6. Was this change discussed? What is the rationale? (FWIW, current implementations disagree about this: e.g., V8 and SM don't throw, JSC does.) /Andreas That assignment still throws per the current ES6 draft. Following 6.2.3.2 PutValue to 9.1.9 [[Set]], step 4.d in [[Set]] creates a dummy data descriptor when no inherited property was found (that way the condition in step 5 will evaluate to true), and step 5.b in [[Set]] returns false if the receiver is not an object. At that point we're back in PutValue, and step 6.d in PutValue will now throw TypeError in strict mode. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Assignment to wrapper objects in strict mode
On 5/28/2014 2:00 PM, Andreas Rossberg wrote: On 28 May 2014 13:41, André Bargull andre.barg...@udo.edu wrote: Apparently, there has been a semantic change between ES5 and ES6 regarding assignment to wrapper objects in strict mode. That is, 'use strict'; .x = 0 would throw in ES5, but AFAICS, no longer does in ES6. Was this change discussed? What is the rationale? (FWIW, current implementations disagree about this: e.g., V8 and SM don't throw, JSC does.) That assignment still throws per the current ES6 draft. Following 6.2.3.2 PutValue to 9.1.9 [[Set]], step 4.d in [[Set]] creates a dummy data descriptor when no inherited property was found (that way the condition in step 5 will evaluate to true), and step 5.b in [[Set]] returns false if the receiver is not an object. At that point we're back in PutValue, and step 6.d in PutValue will now throw TypeError in strict mode. But base will already have been converted to a wrapper object at PutValue step 6.a.ii before you get to [[Set]]. /Andreas The receiver argument in [[Set]] is not the wrapped `base`, but `GetThisValue(V)`, here: the empty string . ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptor can return just about anything
On May 1, 2014, at 2:50 AM, Jason Orendorff jason.orendorff at gmail.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
/
// As specified, proxies can do this:
//
// js Object.isFrozen(proxy)
// true
// js Object.getOwnPropertyDescriptor(proxy).configurable
// true
/
No, that is not the intent. However, Object.isFrozen depends upon the
reliability of [[OwnPropertyKeys]] and one of its checked variants (and this
is not yet in the spec. because Tom, Mark, and I just worked out the final
details last week) is that [[OwnPropertyKeys]] must return a complete and
accurate list of all non-configurable property names.
Also note that Object.isFrozen is specified to operates at the level of the MOP
operations and property descriptor records, not at the
Object.getOwnPropertyDescriptor/descriptor object level. It never looks at the
object that is passed through [[Origin]].
It isn't clear exactly what you intend by the above snippet (does proxy have a
'getOwnPropertyDescriptorHandler'? did you really mean to use undefined as the
property key?). In either case, if the object passes the criteria for isFrozen
then then the con configurable attribute of the resulting descriptor (if the
property exists) must be false and consistent with the target. Steps 11-21 of
9.9.5 (proxy [[GetOwnProperty]] are intended to guarantees that. Maybe there
are bugs in those steps, I can review them in detail right now, but the design
intent is a frozen object can never expose a ;configurable property.
/
// Of course the property is not really configurable. The extent of the
// issue is that Object.getOwnPropertyDescriptor is not a reliable
// reflection API.
/
It's supposed to be for frozen objects, so if you see bugs in that regard I'm
obvious interested.
I think the following example should cover Jason's concerns w.r.t
reliability of Object.getOwnPropertyDescriptor.
Output:
---
Object.isFrozen(target) = true
Object.isFrozen(proxy) = true
Object.getOwnPropertyDescriptor(proxy, propertyName).configurable = true
---
{
let propertyName = propertyName;
let target = Object.freeze({[propertyName]: 0});
let beStupid = false;
let proxy = new Proxy(target, {
getOwnPropertyDescriptor(t, pk) {
if (!beStupid) {
return Reflect.getOwnPropertyDescriptor(t, pk);
}
return {
value: 0, writable: false, enumerable: true,
get configurable() {
delete this.configurable;
this.configurable = true;
return false;
}
};
}
});
print(`Object.isFrozen(target) = ${Object.isFrozen(target)}`);
print(`Object.isFrozen(proxy) = ${Object.isFrozen(proxy)}`);
beStupid = true;
let desc = Object.getOwnPropertyDescriptor(proxy, propertyName);
print(`Object.getOwnPropertyDescriptor(proxy,
propertyName).configurable = ${desc.configurable}`);
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Perhaps @@unscopable shouldn't be a Set...
Where do you find the spec incomplete WRT @@unscopable. My recollection was that it was all resolved and fully specified and that I was relatively happy with the outcome. unscopables for the Object Environment Record is always the empty list. It's never populated. Allen On May 1, 2014, at 3:00 AM, Erik Arvidsson erik.arvidsson at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: / This was never resolved and the spec is incomplete here // // On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock allen at wirfs-brock.com https://mail.mozilla.org/listinfo/es-discuss wrote: // So here is another concern, about the scheme we agreed to last week. // // It needs to match a found own property against the possibility of an own @@unscopable property on the same object and that object may be somewhere up the inheritance chain of the actual with object. The means that [[HasProperty]]/[[Get]]/[[Set]] can not be used to do those resolve binding in an ObjectEnvironmentRecord because they don't tell us where the property was found. Instead, ObjectEnvironmentRecord needs to reimplement its own property lookup using [[GetOwnProperty]] and [[GetInheritanceOf]]. However, if the with object is a proxy that means we may be bypassing the actual inheritance mechanism implemented by the Proxy's 'has'/'get'/'set' traps and that could introduce observable semantics irregularities. // // Specifying the duplicated lookup is doable but a pain. That and the semantic issues WRT proxies makes me a lot less comfortable with the added complexity of supporting @@unscopable. // // Allen / ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Perhaps @@unscopable shouldn't be a Set...
The changes from https://bugs.ecmascript.org/show_bug.cgi?id=1908 never made it into the spec. On 4/30/2014 11:41 PM, André Bargull wrote: Where do you find the spec incomplete WRT @@unscopable. My recollection was that it was all resolved and fully specified and that I was relatively happy with the outcome. unscopables for the Object Environment Record is always the empty list. It's never populated. Allen On May 1, 2014, at 3:00 AM, Erik Arvidsson erik.arvidsson at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: / This was never resolved and the spec is incomplete here // // On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock allen at wirfs-brock.com https://mail.mozilla.org/listinfo/es-discuss wrote: // So here is another concern, about the scheme we agreed to last week. // // It needs to match a found own property against the possibility of an own @@unscopable property on the same object and that object may be somewhere up the inheritance chain of the actual with object. The means that [[HasProperty]]/[[Get]]/[[Set]] can not be used to do those resolve binding in an ObjectEnvironmentRecord because they don't tell us where the property was found. Instead, ObjectEnvironmentRecord needs to reimplement its own property lookup using [[GetOwnProperty]] and [[GetInheritanceOf]]. However, if the with object is a proxy that means we may be bypassing the actual inheritance mechanism implemented by the Proxy's 'has'/'get'/'set' traps and that could introduce observable semantics irregularities. // // Specifying the duplicated lookup is doable but a pain. That and the semantic issues WRT proxies makes me a lot less comfortable with the added complexity of supporting @@unscopable. // // Allen / ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Clarify the destructuring syntax
Hi Erop,
On Fri, Apr 11, 2014 at 12:35 PM, termi1uc1 at gmail.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
/ 1. Should the AssignmentExpression of DestructuringAssignment always to be
// the Object type?
// ```javascript
// let {length} = 123;
// assert(length, 3);
// ```
// Is this valid?
//
/
Yes.
No.
13.2.1.4 Runtime Semantics: Evaluation,
LexicalBinding : BindingPattern Initializer, step 4
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-let-and-const-declarations-runtime-semantics-evaluation
/
// If it is:
// 2. Should the result of Get(obj, name) always be the Object type if
// DestructuringAssignmentTarget is an ObjectLiteral or an ArrayLiteral?
// According the spec 12.14.5.4 step 4.b this expression is invalid:
// ```javascript
// let {text: {length}} = {text: 123};
// assert(length, 3);
// ```
//
/
Yes.
No.
13.2.3.7 Runtime Semantics: KeyedBindingInitialization
BindingElement : BindingPattern Initializer_opt, step 4
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-keyedbindinginitialization
You can test this in the web console in a Nightly or Aurora build of
Firefox.
You can test this in traceur or my test implementation
[https://github.com/anba/es6draft]. ;-)
Maybe the final draft will revert this restriction, it was originally
introduced in rev17. It is somewhat annoying, especially for the string
type, because the restriction also applies to spread array elements and
spread calls. For example `[...abc]` must now be written as `[...new
String(abc)]` to get the array of code points.
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Clarify the destructuring syntax
On 4/11/2014 2:02 PM, Егор Николаев wrote:
@André Bargull
Are there any reasons for these restrictions? It confuses me. If I can
for-of over string, so why can't I destructuring it?
I'd say it's mostly a language designer decision and it may still change
before the final specification is published. I'd encourage you to file
bug reports at https://bugs.ecmascript.org/ and/or post to this mailing
list if you find any issues with the current specification draft. That
way Allen (the spec editor, cc-ed) and other TC-39 members are notified
and can take appropriate actions.
- André
On Fri, Apr 11, 2014 at 3:10 PM, André Bargull andre.barg...@udo.edu
mailto:andre.barg...@udo.edu wrote:
Hi Erop,
On Fri, Apr 11, 2014 at 12:35 PM, Егор Николаев termi1uc1 at gmail.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
/ 1. Should the AssignmentExpression of DestructuringAssignment always to
be
/
/the Object type? //```javascript //let {length} = 123;
//assert(length, 3); //``` //Is this valid? /// Yes.
No.
13.2.1.4 Runtime Semantics: Evaluation,
LexicalBinding : BindingPattern Initializer, step 4
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-let-and-const-declarations-runtime-semantics-evaluation
/
// If it is:
// 2. Should the result of Get(obj, name) always be the Object type if
// DestructuringAssignmentTarget is an ObjectLiteral or an ArrayLiteral?
// According the spec 12.14.5.4 step 4.b this expression is invalid:
// ```javascript
// let {text: {length}} = {text: 123};
// assert(length, 3);
// ```
//
/
Yes.
No.
13.2.3.7 Runtime Semantics: KeyedBindingInitialization
BindingElement : BindingPattern Initializer_opt, step 4
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-keyedbindinginitialization
You can test this in the web console in a Nightly or Aurora build of
Firefox.
You can test this in traceur or my test implementation
[https://github.com/anba/es6draft]. ;-)
Maybe the final draft will revert this restriction, it was
originally introduced in rev17. It is somewhat annoying, especially
for the string type, because the restriction also applies to spread
array elements and spread calls. For example `[...abc]` must now
be written as `[...new String(abc)]` to get the array of code points.
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptors(O) ? // plural
I would rephrase into this: if you need a getOwnPropertyNames trap, you might need for consistency a getOwnPropertySymbols independently from getOwnPropertyDescriptors since these methods are already available. While it shares the same name with Object.getOwnPropertyNames(), this getOwnPropertyNames trap is supposed to return string and symbol keyed properties, see http://esdiscuss.org/topic/ownpropertykeys . I also would like to add a couple of links to support the fact getOwnPropertyDescriptors is needed, and has been asked for, since quite a while: this was 11th of November 2011 ... I didn't know it, and now that I do I wonder why this has been post-poned for so long and never discussed again. https://mail.mozilla.org/pipermail/es-discuss/2011-November/018275.html Or even earlier, http://wiki.ecmascript.org/doku.php?id=strawman:extended_object_api from 2010. Best Regards On Thu, Mar 6, 2014 at 11:24 AM, C. Scott Ananian ecmascript at cscott.net https://mail.mozilla.org/listinfo/es-discusswrote: / If you use a getOwnPropertyNames trap, then you also need a // getOwnPropertySymbols trap to implement getOwnPropertyDescriptors. // --scott // // On Thu, Mar 6, 2014 at 2:16 AM, Tom Van Cutsem tomvc.be at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: // 2014-03-05 20:11 GMT+01:00 C. Scott Ananian ecmascript at cscott.net https://mail.mozilla.org/listinfo/es-discuss: // // On Wed, Mar 5, 2014 at 1:39 PM, Tom Van Cutsem tomvc.be at gmail.com https://mail.mozilla.org/listinfo/es-discuss // wrote: //Object.getOwnPropertyDescriptors(proxy) would trigger the //getOwnPropertyNames trap, followed by calls to the //getOwnPropertyDescriptor //trap for each individual property. // // [[OwnPropertyKeys]], `ownKeys` trap. // // // Yes, according to the current draft spec. I have a pending discussion // with // Allen that we actually need to reintroduce a [[GetOwnPropertyNames]] // internal method / getOwnPropertyNames trap, as the `ownKeys` trap // doesn't do // any invariant checking, which is needed for a reliable Object.isFrozen // test. // // Regards, // Tom / ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptors(O) ? // plural
On 3/6/2014 10:24 PM, Brendan Eich wrote: André Bargull mailto:andre.barg...@udo.edu March 6, 2014 at 1:21 PM I would rephrase into this: if you need a getOwnPropertyNames trap, you might need for consistency a getOwnPropertySymbols independently from getOwnPropertyDescriptors since these methods are already available. While it shares the same name with Object.getOwnPropertyNames(), this getOwnPropertyNames trap is supposed to return string and symbol keyed properties, see http://esdiscuss.org/topic/ownpropertykeys . Should the trap end in Keys not Names? /be Only if [[OwnPropertyKeys]] gets renamed to something else, because having both [[GetOwnPropertyKeys]] and [[OwnPropertyKeys]] seems unnecessarily confusing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptors(O) ? // plural
On 3/6/2014 11:35 PM, Andrea Giammarchi wrote: autocomplete misspelled Andre' , apologies No worries! :-) On Thu, Mar 6, 2014 at 2:34 PM, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote: Thanks Andrew, I wonder if I should update the proposed spec somehow, but I thought as it is combines both Names and Symbols as abstract. You mean this proposal https://gist.github.com/WebReflection/9353781, right? It does not need to be changed, because the [[OwnPropertyKeys]] internal method returns string and symbol valued property keys. Or to be more correct, it returns string and symbol valued property keys for ordinary objects. Proxy objects are currently allowed to return any value from their [[OwnPropertyKeys]] internal method, because the result value of the ownKeys trap is not checked at all. (Except of a simple type check to ensure it is an object.) The proposed [[GetOwnPropertyNames]] internal method is supposed to be a more restrictive version of [[OwnPropertyKeys]] to ensure Proxy objects don't lie about their properties. This is only required for certain integrity critical methods, like for example Object.isFrozen(). Please let me know and I'll update. Best Regards On Thu, Mar 6, 2014 at 1:21 PM, André Bargull andre.barg...@udo.edu mailto:andre.barg...@udo.edu wrote: I would rephrase into this: if you need a getOwnPropertyNames trap, you might need for consistency a getOwnPropertySymbols independently from getOwnPropertyDescriptors since these methods are already available. While it shares the same name with Object.getOwnPropertyNames(), this getOwnPropertyNames trap is supposed to return string and symbol keyed properties, see http://esdiscuss.org/topic/ownpropertykeys . I also would like to add a couple of links to support the fact getOwnPropertyDescriptors is needed, and has been asked for, since quite a while: this was 11th of November 2011 ... I didn't know it, and now that I do I wonder why this has been post-poned for so long and never discussed again. https://mail.mozilla.org/pipermail/es-discuss/2011-November/018275.html Or even earlier, http://wiki.ecmascript.org/doku.php?id=strawman:extended_object_api from 2010. Best Regards On Thu, Mar 6, 2014 at 11:24 AM, C. Scott Ananian ecmascript at cscott.net https://mail.mozilla.org/listinfo/es-discusswrote: / If you use a getOwnPropertyNames trap, then you also need a / /getOwnPropertySymbols trap to implement getOwnPropertyDescriptors. //--scott /// / On Thu, Mar 6, 2014 at 2:16 AM, Tom Van Cutsem tomvc.be at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: // 2014-03-05 20:11 GMT+01:00 C. Scott Ananian ecmascript at cscott.net https://mail.mozilla.org/listinfo/es-discuss: // // On Wed, Mar 5, 2014 at 1:39 PM, Tom Van Cutsem tomvc.be at gmail.com https://mail.mozilla.org/listinfo/es-discuss / /wrote: // Object.getOwnPropertyDescriptors(proxy) would trigger the // getOwnPropertyNames trap, followed by calls to the // getOwnPropertyDescriptor // trap for each individual property. // // [[OwnPropertyKeys]], `ownKeys` trap. // // // Yes, according to the current draft spec. I have a pending discussion //with // Allen that we actually need to reintroduce a [[GetOwnPropertyNames]] // internal method / getOwnPropertyNames trap, as the `ownKeys` trap //doesn't do // any invariant checking, which is needed for a reliable Object.isFrozen //test. // // Regards, // Tom / ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
On 2/14/2014 11:40 PM, C. Scott Ananian wrote: On Fri, Feb 14, 2014 at 11:50 AM, André Bargull andre.barg...@udo.edu wrote: I think Scott is requesting this change: https://gist.github.com/anba/6c75c34c72d4ffaa8de7 Yes, although my proposed diff (in the linked bug) was the shorter, 12. If end is undefined, let relativeEnd be ToInteger(lenVal); else let relativeEnd be ToInteger(end). Same effect, though. It's not the same effect, because `lenVal` could be an object with valueOf/toString/@toPrimitive side-effects. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On 30/01/2014, at 17:13, Brendan Eich wrote: / // // Interesting! // // You don't want the alert to show undefined, so the extent of the inner binding in your model is the unbraced consequent of the if. // // That is not block scope in any plain sense. / How about this? let x= 0; if (1) eval(let x= 42; alert(x);); //Is this in its own block? alert(x); `eval()` hasn't yet been updated to work with the new lexical declaration forms, but I hope the example from above will be evaluated in a new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug report. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote: / For reference:https://bugs.ecmascript.org/show_bug.cgi?id=2546 // // `Array#copyWithin` has a (non-normative) signature of `(target, start, // end = this.length)`. However, this is slightly misleading because the // spec actually calls `ToLength` on `this.length` and then uses *that* // for the default value of `end`. This changes `end`'s effective value // when `this.length` is negative. // // In the bug we discuss changing the non-normative descriptive text to // be less misleading. // // But I'd like to invite broader discussion on a different approach: can // we change the spec so that the `end = this.length` default was // actually correct? This would only possibly change behavior on // array-likes with negative length, and probably wouldn't even change // observable behavior in that case (since `length` is treated as 0). // Basically we'd be just calling `ToInteger` on the default value of // `end` rather than `ToLength`. But it would be an end-run around // confusing language in the spec. // --scott / ToLength is used a number of places within the ES6 spec. where formerly ToUint32 was used. It allows indices to be larger 2^32-2 and avoids weird wrap behavior for indices in that range. I doubt that we could compatibly get away with replacing those legacy ToUnit32 calls with a ToLength that preserved negative values. Even if we could we would have to review all of the array (and string) algorithms that use ToLength to make sure they still work reasonably with negative length values. I really don't see what benefit we would get from that work. Allen I think Scott is requesting this change: https://gist.github.com/anba/6c75c34c72d4ffaa8de7 - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't unambiguously figure out which browser is 'correct'. There are a few edge cases in reference resolution which are not correctly implemented in most browsers. Your example is basically the same as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section in the specification is 12.13.4 Runtime Semantics: Evaluation: The left hand side of an assignment is always evaluated before the right hand side. This includes resolving and remembering the reference information for an identifier reference. In this case the identifier reference resolves to a binding on the global object, so assignment must be performed on the global, even if a (direct) eval expression introduces new bindings with the same name in the current scope. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/26/2013 02:28 PM, Claude Pache wrote:
/ From the thread [1], I guess that parsing correctly the following thing
would be obnoxious (at best)?
//
// (a = yield/b/g) =* {}
//
// ---Claude
/
Indeed.
And you can make even more obnoxious parses of the hypothetical combination of
=*, default parameters, and retroactive yield-scope:
(a = yield//) =* (//g)
Are the two //'s regexps or is /) =* (/ a string token?
Waldemar
Are you sure? The `(a = yield/b/g)` part is parsed at first as a
parenthesised expression and only later (after the `=` token)
reinterpreted as an ArrowFormalParameters grammar production.
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/27/2013 12:07 AM, Waldemar Horwat wrote:
On 11/26/2013 03:00 PM, André Bargull wrote:
On 11/26/2013 02:28 PM, Claude Pache wrote:
/ From the thread [1], I guess that parsing correctly the
following thing would be obnoxious (at best)?
//
// (a = yield/b/g) =* {}
//
// —Claude
/
Indeed.
And you can make even more obnoxious parses of the hypothetical
combination of =*, default parameters, and retroactive yield-scope:
(a = yield//) =* (//g)
Are the two //'s regexps or is /) =* (/ a string token?
Waldemar
Are you sure? The `(a = yield/b/g)` part is parsed at first as a
parenthesised expression and only later (after the `=` token)
reinterpreted as an ArrowFormalParameters grammar production.
- André
Fine, so do this one instead:
(a = yield//g, b = yield//g) =* {}
Does this generator have one or two parameters?
It depends on the surrounding environment.
Lexical token sequence in function environment:
LP
Ident[a] Assign Ident[yield] Div String Div Ident[g]
RP
Lexical token sequence in generator environment:
LP
Ident[a] Assign Yield RegExp
Comma
Ident[b] Assign Yield RegExp
RP
Reinterpreting the lexical token sequence per [14.2]:
It is a Syntax Error if the lexical token sequence matched by
CoverParenthesisedExpressionAndArrowParameterList cannot be parsed with no
tokens left over using
ArrowFormalParameters as the goal symbol.
And applying the current (rev21) grammar production rule
`FormalParameters[Yield,GeneratorParameter]` [14.4], gives either a
generator with a single parameter (if in function environment) or a
SyntaxError (if in generator environment). The SyntaxError is emitted
because `FormalParameters[Yield,GeneratorParameter]` does not allow
YieldExpressions [13.2.3], instead yield is treated as an
IdentifierReference in function default parameters.
If the term parsing a lexical token sequence allows you to go back to
the source character level, the result will be different, of course.
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Novel operator syntax
Got it, thanks. We could indeed do .+, .*, etc. without ambiguity. (Ignore E4X's wildcards: xml.* etc.!) /be No. ;-) js 1.*2 2 - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Novel operator syntax
On 10/29/2013 7:51 PM, Tristan Zajonc wrote: Right you are. That was the same issue with Python. Are there any blockers to ~*? There are the usual ASI problems. For example this is currently valid: ``` a ~+ b ``` It is parsed as: ``` a; ~+ b; ``` On Tue, Oct 29, 2013 at 11:46 AM, André Bargull andre.barg...@udo.edu mailto:andre.barg...@udo.edu wrote: Got it, thanks. We could indeed do .+, .*, etc. without ambiguity. (Ignore E4X's wildcards: xml.* etc.!) /be No. ;-) js 1.*2 2 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign and __proto__ property
Traceur has:
function assign(target, source) {
var props = $getOwnPropertyNames(source);
var p, length = props.length;
for (p = 0; p length; p++) {
target[props[p]] = source[props[p]];
}
return target;
}
Which is correct.
Almost correct ;-)
Exception handling and enumerable checks are missing. And calling
$getOwnPropertyNames() is not fully compatible when compared to
[[OwnKeys]] in some Proxy corner cases [1], but that's difficult to get
right in ES5 code.
[1]
https://github.com/anba/es6draft/blob/master/src/test/scripts/suite/objects/Object/assign.js#L166-L181
A more conformant implementation should be this one:
function assign(target, source) {
function ToObject(o) {
if (o == null) {
throw new TypeError();
}
return Object(o);
}
var to = ToObject(target);
var from = ToObject(source);
var keys = $getOwnPropertyNames(from);
var pendingException = null;
for (var i = 0, length = keys.length; i length; ++i) {
var nextKey = keys[i];
try {
var desc = $getOwnPropertyDescriptor(from, nextKey);
if (desc !== undefined desc.enumerable) {
to[nextKey] = from[nextKey];
}
} catch (e) {
if (pendingException !== null) {
pendingException = e;
}
}
}
if (pendingException !== null) {
throw pendingException;
}
return to;
}
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign and exceptions (was: Object.assign and __proto__ property)
On 10/22/2013 4:00 PM, Erik Arvidsson wrote:
The spec for Object.assign,
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign,
seems to have some issues.
/gotAllNames/ is never read.
It is initialised to false in step 7, read in step 9 and set to true in
step 9c. That seems to be ok.
What is the intention regarding exceptions? Is the intention to continue
assigning properties after an exception is thrown. Why is that the
desired behavior?
I'd guess to align behaviour with Object.mixin, Object.defineProperties,
(Object.create), Object.is{Sealed,Frozen} and Object.seal/freeze. This
was also covered in the thread starting at
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027067.html .
- André
On Tue, Oct 22, 2013 at 6:41 AM, André Bargull andre.barg...@udo.edu
mailto:andre.barg...@udo.edu wrote:
...
A more conformant implementation should be this one:
function assign(target, source) {
function ToObject(o) {
if (o == null) {
throw new TypeError();
}
return Object(o);
}
var to = ToObject(target);
var from = ToObject(source);
var keys = $getOwnPropertyNames(from);
var pendingException = null;
for (var i = 0, length = keys.length; i length; ++i) {
var nextKey = keys[i];
try {
var desc = $getOwnPropertyDescriptor(from, nextKey);
if (desc !== undefined desc.enumerable) {
to[nextKey] = from[nextKey];
}
} catch (e) {
if (pendingException !== null) {
pendingException = e;
}
}
}
if (pendingException !== null) {
throw pendingException;
}
return to;
}
- André
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
/ I disagree. In those situations you should just iterate over the string using `for...of`. / That seems to iterate over code units as far as I can tell. for (var x of ?) print(x.charCodeAt(0)) invokes print() twice in Gecko. SpiderMonkey does not implement the (yet to be) spec'ed String.prototype.@@iterator function, instead it simply aliases String.prototype[@@iterator] to Array.prototype[@@iterator]: js String.prototype[@@iterator] === Array.prototype[@@iterator] true - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
Follow up question for Tom et al...
Using require('harmony-reflect')
var t = {a:3, c:4};
var p = Proxy(
t,
{
get: function() {},
delete: function(t,x) {
console.log('deleting');
delete t.a;
}
}
);
delete p.c
p; //{a:3}
t; //{a:3}
the console.log is not called and deleting is not trapped.
Am I doing something wrong?
The trap name for the `delete` operator is deleteProperty instead of
delete...
@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 4:01 PM, Allen Wirfs-Brock wrote:
/
// On Oct 18, 2013, at 1:29 PM, Allen Wirfs-Brock wrote:
//
// Array.from( '???'))[1]
//
// maybe even better:
//
// Uint32Array.from( '???'))[1]
/
err...maybe not if you want a string value:
String.fromCodePoint(Uint32Array.from( '???')[1])
That does not seem to be too useful:
js String.fromCodePoint(Uint32Array.from(\u{1d306}\u{1d306}\u{1d306})[1])
\u
According to
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html#String,
String.prototype[@@iterator] does not return plain code points, but the
String value for the code point.
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin, why just for enumerables (?)
Object.mixin, why just for enumerables (?) It's a copy-paste error in the draft: https://bugs.ecmascript.org/show_bug.cgi?id=1999#c1 This is related to: http://mozilla.6506.n7.nabble.com/Object-define-Object-mixin-tp265638p265651.html In a spec we have both Object.assign and Object.mixin. Object.assign is for copying properties ES3 way, which even in ES5 world is what you want in most cases (btw. I don't agree with http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/ For 3 years I work strictly with ES5, and I never had a case in which I wanted to just copy enumerables and preserve getters, it's highly unwanted in all cases I had). Object.mixin is for copying definitions, which I find as rare but also valid use case, e.g. to mimic multiple inheritance by copying properties from one prototype to other. However this cannot work as intended if it's limited just for enumerables. All properties in native prototypes are already defined as not enumerable, and this is also what I follow in my code when I define models. So as specified currently I find Object.mixin as a function that I don't find valid use case for, and I strongly miss something like Object.assignDefinitions, which will copy properties by descriptors, no matter whether they're enumerable or not. /Mariusz ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Clarification on function default param values
/ Brandon Benvie mailto:bbenvie at mozilla.com
https://mail.mozilla.org/listinfo/es-discuss
// September 30, 2013 8:48 PM
// I'm actually now really curious what the following does:
//
// ```
// function foo(x, y = (() = { arguments[0] = foo; return bar })()) {
//return [x, y];
// }
/
Easy: arguments is an early error in the body of an arrow.
http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax
/be
This restriction is not specified in the rev19 draft. Currently arrow
functions don't have an own `arguments` binding, but instead access the
outer functions `arguments` object, similar to `this`. Disallowing the
identifier arguments in PrimaryExpressions also should imply
disallowing arguments as a BindingIdentifier, which shifts arrow
functions again into almost strict-mode.
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: bugs.ecmascript.org appears to be down
Could someone give it a nudge? -Michael Per #it on irc.mozilla.org scl3 is down, apparently some maintenance work per user Usul. So not only bugs.ecmascript.org. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: bugs.ecmascript.org appears to be down
On 9/29/2013 7:51 PM, André Bargull wrote: Could someone give it a nudge? -Michael Per #it on irc.mozilla.org scl3 is down, apparently some maintenance work per user Usul. So not only bugs.ecmascript.org. - André (10:51:27) wicked: how long will it take? (10:51:45) digi: wicked: just some background - we're doing some maintenance in our scl3 data center. I think the window is open until 1pm. (10:51:55) digi: we're performing some upgrades which isn't expected to have a big impact (10:52:03) digi: but as you just witnessed there is the possibility for connectivity to be intermittent ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Comments on Sept Meeting Notes
/ Whether you personally use it, for-in is a reality. Introspection of
// objects happens, so if you ship a library that's putting meta-level
// properties into objects it needs to make them non-enumerable to be robust
// in the face of client code that uses for-in but isn't prepared to
// understand the meta properties.
//
//
/Is there a concrete example which shows how enumerability of meta-level
properties would present a problem for such code? That might be convincing.
There are all kinds for-in uses which don't expect meta-level hooks. For
example this isEmpty function to test whether an object contains any
entries:
js```
function isEmpty(o) {
for (var k in o) return false;
return true;
}
```
In this case I doubt @iterator or @toStringTag should be visible. (And I
know there a better ways to test for empty objects, but for-in testing
is common enough...)
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Comments on Sept Meeting Notes
On 9/27/2013 9:58 PM, Kevin Smith wrote:
In this case I doubt @iterator or @toStringTag should be visible.
(And I know there a better ways to test for empty objects, but
for-in testing is common enough...)
Thanks Andre! I fear this example merely begs the question of whether
such an object should be considered empty with respect to
enumerability. Would anything break if the following object were
considered not empty?
var obj = { @iterator() { /* ... */ } };
More generally, what is accomplished by hiding these hooks from for-in?
Whether or not some code breaks depends on how that function is used, so
it's hard for me to give a general answer at this point. Concerning your
second question about the benefits of hiding hooks: I'd assume if
something is a meta-level hook, it should only be visible on the
meta-level and not on the concrete data level. And for-in is rather a
tool to access the concrete data level than to access the meta-level.
PS: The function is called isEmptyObject in jQuery -
https://github.com/jquery/jquery/blob/master/src/core.js#L267-L273
- André
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls
Short summary:
The current (rev18) [[Invoke]] design allows this code to work (use case A):
js```
var p = new Proxy(new Map, {});
// Map.prototype.get is not generic, requires proper Map instance
p.get(key);
```
But it does not allow to use (use case B):
js```
var p = new Proxy(new Map, {});
Map.prototype.get.call(p, key);
```
To make sure use case B works as well, [[InvokeFunction]] and changing
Function.prototype.{call, apply} has been proposed. Proxies will also
receive a new trap for [[InvokeFunction]]. Function.prototype.call will
need to be changed as follows:
Change last step (step 4) from:
4. Return result of func.[[Call]] (thisArg, argList).
To:
4. If Type(thisArg) is Object then
4.a Return result of thisArg.[[InvokeFunction]] (func, argList).
5. Else
5.a Return result of func.[[Call]] (thisArg, argList).
(Note: The condition in step 4 may explicitly test for Proxies and only
dispatch [[InvokeFunction]] if that's the case -- but this is not too
important for now.)
The following objections have been raised so far:
(1) Calling Function.prototype.call on a function object no longer
ensures the function object will be called.
(2) Calling Function.prototype.call on a function object let's the
function object escape to the proxy object.
Example for (1):
js```
function thrower() { throw new Error }
var p = new Proxy({}, {invokeFunction(f, args) { /* do nothing */ }});
// no exception will be thrown here
thrower.call(p);
```
Example for (2):
See Kevin's example below.
In response to these objections, it was said that `Reflect.call()` will
need to be used to ensure the original [[Call]] behaviour takes place.
- André
Ok, I've only been skimming the thread but I obviously missed something
crucial. How would
f.call(obj)
cause obj's handler to be invoked at all, much less be given access to f?
And why?
On Mon, Sep 23, 2013 at 7:14 PM, Allen Wirfs-Brock allen at wirfs-brock.com
https://mail.mozilla.org/listinfo/es-discusswrote:
/ Sorry, I meant obj's handler
//
//
// Mark S. Miller erights at google.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
//
// What does f's handler refer to? If obj is a proxy and f is not, then obj
// has a proxy and f does not.
//
//
// On Mon, Sep 23, 2013 at 6:32 PM, Allen Wirfs-Brock allen at wirfs-brock.com
https://mail.mozilla.org/listinfo/es-discusswrote:
//
//
// On Sep 23, 2013, at 6:14 PM, Kevin Smith wrote:
//
// Hi Allen,
//
// Your line of thinking has convinced me that `invoke` as it currently
// stands doesn't really fly. However, I have an issue with your proposal.
// Take this fragment:
//
// (1) function f() { doSomethingWith(this); }
// (2) f.call(obj);
//
// Presently, the expression at (2) grants the function `f` access to
// `obj`. If I understand correctly, under your proposal the expression at
// (2), in the case where `obj` is a proxy, additionally grants `obj` access
// to `f`. Is that right?
//
// In the case where obj is a Proxy f.call(obj) would give f's handler
// access to f.
//
// Allen/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Removing Proxy hasOwn() trap (Was: [[Invoke]] and implicit method calls)
On Sep 24, 2013, at 8:13 AM, Jason Orendorff wrote: / On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem tomvc.be at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: // [forking from [[invoke]]-thread for clarity] // // Thanks! // // Allen: would the removal of the hasOwn() trap imply that we can drop the // [[HasOwnProperty]] internal method altogether? / I look at the the opposite way -- we have an 'hasOwn' trap because be have a [[HasOwnProperty]] internal method ;-) I pretty sure we discussed this before and decided we wanted to keep [[HasOwnProperty]]. However, the only reason I can think of for doing so now is to avoid forcing exotic objects to allocated the property descriptors that [[GetOwnProperty]] produces. Exotic string and integer indexed objects ( = TypedArray instances) provide custom implementations for [[HasOwnProperty]] for exactly this reason. / // I searched the spec. There are not very many places where // [[HasOwnProperty]] is used; each one can be replaced with a call to an // Abstract Operation defined like this: / Right, an none of the places seem particularly performance sensitive. In particular, ordinary property lookup uses [[GetOwnProperty]] rather than [[HasOwnProperlty]] [[HasProperty]] for ordinary objects also uses [[HasOwnProperty]]. So this needs to be taken into account when searching for performance sensitive calls. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls
Back to option 2: Redesign [[Invoke]] from https://mail.mozilla.org/pipermail/es-discuss/2013-August/032718.html ? - André What if we made invoke take either an identifier to call, or a got function to call? Then get+invoke would pass the got function. /be Allen Wirfs-Brock mailto:al...@wirfs-brock.com September 19, 2013 1:39 PM Seems very unlikely. The @@hasInstance access is new so it isn't a backwards compat issue. BTW, these are static counts. For example, a typical call to ToPrimitive will only make a single such conditional invoke. Arguably allowing a String or Number wrapper to be transparently proxied and hence work like a unproxied wrapper WRT ToPrimitive is one the reasons we need to do this. Allen [...] ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Removal of NoIn grammar productions and for-loop parsing
The NoIn grammar productions have been removed in rev17. Does this mean that `for (a in b;;);` is now a valid (C-style) for-loop instead of a SyntaxError? Thanks, André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.prototype.slice web-compat issue?
This test case [1] from SpiderMonkey failed when I applied the latest spec changes to my ES6 test implementation. Based on the bug report at [2], this might be another web-compatibility issue - but is that really the case? Any input appreciated! Thanks, André [1] https://github.com/mozilla/mozilla-central/blob/master/js/src/jit-test/tests/basic/bug683140.js [2] https://bugzilla.mozilla.org/show_bug.cgi?id=683140 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The generator.next() method
`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value
is needed here. Or do you mean something else?
Thanks,
André
No .value anywhere, though.
/be
Forbes Lindesay wrote:
/ It already is dealt with via destructuring assignments:
//
// ```js
// function* gen() {
// var {x, y, z} = yield [1, 2, 3]
// return x y || z
// }
// var g = gen()
// var [a, b, c] = g.next().value
// assert(a === 1)
// assert(b === 2)
// assert(c === 3)
// var res = g.send({x: true, y: false, z: true}).value
// assert(res === true)
// ```/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Lexical scoping of 'function' in sloppy mode breaks legal ES5
On 19 August 2013 19:02, Allen Wirfs-Brock allen at wirfs-brock.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
/
// On Aug 19, 2013, at 8:38 AM, Andreas Rossberg wrote:
//
// While debugging a V8 issue I just realised another incompatibility
// with introducing lexical function declarations in sloppy mode that I
// think we haven't observed yet. Consider the following code:
//
// function f() {
// var x = 0
// try {
// throw 1
// } catch (x) {
// eval(function g() { return x })
// }
// return g()
// }
//
// This function is legal, and supposed to return 1 according to my
// reading of the ES5 spec.
//
// I don't think so. according to ES5 10.4.2 The VariableEnvironment of the eval'ed
code should be set to the VariableEnvironment of the calling context. That variable
environment is the outer cope of function f that has 0 as the value of its x binding. When g
is instantiated that variable environment will be its [[Scope]] so return x
should return 0.
/
You are right, although the discrepancy between FunctionExpression and
FunctionDeclaration feels really odd -- I wonder how that came about.
It also means that both Firefox and Safari handle the example
incorrectly (though at least they don't crash :) ).
This difference was introduced between 8. Dec. 2008 and 15. Dec. 2008,
in the earlier drafts both, function declarations and function
expressions, used the LexicalEnvironment of the running execution
context for their [[Scope]]. And this is also what ES3 specified (Pass
in the scope chain of the running execution context as the Scope.). So
maybe this is just another bug in the ES5 specification?
Source:
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: GeneratorFunctionPrototype should probably be a function
Hi,
Section 15.19.3.3 of the July 15 draft says:
Properties of the GeneratorFunction Prototype Object
The GeneratorFunction prototype object is an ordinary object. It is
not a function object and does not have a [[Code]] internal data
property or any other of the internal data properties listed in
Table 13. In addition to being the value of the prototype property
of the %GeneratorFunction% intrinsic and is itself the %Generator%
instrinsic.
Seehttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.19.3
http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-15.19.3 for
the gnarlies. To be explicit, we are talking about this object:
var GeneratorFunctionPrototype = function*(){}.__proto__;
I think this object should be a function and not a normal object.
1. The spec doesn't specify any other objects for which x instanceof
Function that aren't functions.
Isn't that just because no other object inherits from the Function
object in the specification? For example on the user level you can write
`class MyFunction extends Function {}`, where `MyFunction.prototype
instanceof Function` yields true, but `typeof MyFunction.prototype` is
still object. IIRC Allen even spec'ed GeneratorFunction similar to if
it was written in the class syntax.
2. Function.prototype.toString is the binding for .toString() on
this object, but it is only applicable to function receivers.
The same restriction also applies to Number, String, Boolean, RegExp and
Date (or rather to the corresponding prototype objects). So this is not
a unique behaviour w.r.t. the GeneratorFunction prototype object.
Sending here as I seem to have forgotten my bugzilla password, and the
mail is taking too long to get here. Sorry 'bout that.
Regards,
Andy.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy-for-array transparency issues
/ * ArrayBuffer.isView // yup. The use cases for isView aren't all that clear to me. It could be // expressed a @@isView test if it has important use cases. / I'm not familiar enough with ArrayBuffers to understand the consequences. By analogy with Array.isArray, if a proxy-for-arraybuffer automatically upholds all observable invariants of ArrayBuffers, then arguably the test should return true for proxies. What would be the observable invariants of an ArrayBuffer? ArrayBuffer.isView() should not return `true` for exotic array objects. That was just a spec bug, fixed in rev16 (https://bugs.ecmascript.org/show_bug.cgi?id=1570). As currently spec'ed, ArrayBuffer.isView() only returns true for TypedArray objects and DataView objects (both kind of objects have got a [[ViewedArrayBuffer]] internal data property). And there are no observable invariants which can be used for this case. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Completion Records
Looking at the ES6 spec draft, I've drawn the following conclusions
about Completion Records. Can someone confirm?
If [[type]] is 'normal', 'return', or 'throw',
[[target]] must be 'empty' (can't be an identifier).
Moreover, if [[type]] is 'return' or 'throw',
[[value]] must be a language value (can't be 'empty').
Looks reasonable but I haven't verified it myself.
If [[type]] is 'continue' or 'break', no restrictions:
[[target]] can be 'empty' or an Identifier,
[[value]] can be 'empty' or a language value,
and all combinations can occur.
...
The only ones whose existence is less than obvious are those where:
[[type]] is 'continue' or 'break', and [[value]] is a language value
I can see in the pseudo-code the points where they could be created
(in 12.1.1.2, 12.11.1.2, and 14.1.2), but I haven't tried to reverse-
engineer a program that would cause it to happen. Could someone explain
why it's useful to allow such Completion Records, and post a snippet of
code that would cause one to be created?
12.1.1.2 is the important one here. For example take this test case
which is expected to return value:
---
L1:
do
{
value; Completion {[[type]]: normal, [[value]]: value,
[[target]]: empty}
break L1; Completion {[[type]]: break, [[value]]: empty,
[[target]]: L1}
} Completion {[[type]]: break, [[value]]: value,
[[target]]: L1}
while(false); Completion {[[type]]: normal, [[value]]: value,
[[target]]: empty}
---
'continue' works the same and just ignore for now that 12.6.1.1 step 2.c
in the current draft is invalid (it needs to add an additional step to
convert a break completion value to a normal completion value, cf.
12.6.1 in the ES5.1 spec).
14.1.2 is only needed to inspect the completion record value:
eval('L1: do { value; break L1; } while(false);') === value
Thanks,
-Michael
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Allen (cc-ed) changed symbols back to objects in draft rev 16 (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. - André I see. That's unpleasant. In ES5, Object(x) can never throw, and so the code paths using |x === Object(x)| are not prepared for a throw. Much old code will break. On Mon, Jul 15, 2013 at 8:01 AM, Jeremy Martin jmar777 at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: / s === Object(s) // // This should throw a TypeError. In the case of a Symbol, `Object(*value*)` // results in `ToObject(*value*)` [1]. And, in the case of Symbol, ToObject // should throw a TypeError [2]. // // [1]http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-15.2.1.1 // [2]http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9 http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-9.1.9 // // On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erights at google.com https://mail.mozilla.org/listinfo/es-discusswrote: // // Given that s is a Symbol and b is a Bignum, is // // s === Object(s) // // ? // // Is // // b === Object(b) // // ? // // The reason I ask is that x === Object(x) is often used to distinguish // primitive values from objects. The other thing that's often used is typeof, // but these uses of typeof usually assume that the full range of possible // answers is already known. If we're going to be expanding the typeof // answers, then we need guidance on how to write this test now (es5) such // that it stays robust. // // // -- // Cheers, // --MarkM// https://mail.mozilla.org/listinfo/es-discuss // // // -- // Jeremy Martin // 661.312.3853 // http://devsmash.com // @jmar777 // / -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
On Thu, Jul 11, 2013 at 11:52 PM, Zbigniew Braniecki zbraniecki at mozilla.com https://mail.mozilla.org/listinfo/es-discuss / wrote: [...] // /1) CanonicalizeLanguageTag [1] / // Because language tags come from developers and users, ability to // canonicalize them is crucial to us. ECMA 402 specifies this function and // all we need is to expose it in the API // / I was thinking the same thing recently, at least for CanonicalizeLanguageTag. I was working with a platform that gave me a language tag in non-canonical form, meaning I had to either canonicalize it or rename my language files to match the same non-canonical form. Exposing it as `Intl.canonicalizeLanguageTag(tag)` seems like a good idea. Only exposing CanonicalizeLanguageTag does not seem useful to me without having access to IsStructurallyValidLanguageTag. Most likely a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is necessary/wanted for most use cases. / // 1.1) CanonicalizeLocaleList [2] // // That would also be nice to have :) // / I don't think you could expose CanonicalizeLocaleList directly without altering it to return an array, you'd have to do something similar to step 5 of LookupSupportedLocales. I'm not sure we could change that function in the spec without other abstracts potentially being affected by tainted a Array.prototype, so I guess you'd need to specify a new function. In which case I'm wondering if maybe you'd be better off with `Intl.canonicalizeTags(tags)` which would cover both CanonicalizeLanguageTag() and CanonicalizeLocaleList(). I don't see why you'd need to change CanonicalizeLocaleList at all. Just let it return the internal list as-is, and then define `Intl.canonicalizeLocaleList` like so: Intl.canonicalizeLocaleList(locales): 1. Let canonicalizedLocaleList be the result of CanonicalizeLocaleList(locales). 2. ReturnIfAbrupt(canonicalizedLocaleList). 3. Return CreateArrayFromList(canonicalizedLocaleList). (ReturnIfAbrupt and CreateArrayFromList are defined in ES6 as internal abstract operations.) It also needs to be considered whether the duplicate removal in CanonicalizeLocaleList creates any issues for users of a potential `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
On 7/13/2013 8:48 PM, Andy Earnshaw wrote: On Sat, Jul 13, 2013 at 1:05 PM, André Bargull andre.barg...@udo.edu mailto:andre.barg...@udo.edu wrote: ... Only exposing CanonicalizeLanguageTag does not seem useful to me without having access to IsStructurallyValidLanguageTag. Most likely a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is necessary/wanted for most use cases. Hmm. I'm not sure I'd agree it's necessary. IsStructurallyValidLanguageTag makes sense as an abstract function because you need to throw accordingly when an invalid tag is passed to the constructors or methods. However, it's still the developer's responsibility to make sure their tags are valid during the development process. Canonicalisation would still throw an error if the tag is invalid. CanonicalizeLanguageTag isn't even defined for non-structurally valid language tags. That's why I meant a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is more useful than access to the bare CanonicalizeLanguageTag function. I don't see why you'd need to change CanonicalizeLocaleList at all. Just let it return the internal list as-is, and then define `Intl.canonicalizeLocaleList` like so: Lists are internal, they aren't part of the ECMAScript language. It makes no sense to return an internal list to ECMAScript code unless you intend to go the whole hog and specify them with a constructor/prototype. The internal list structure is not returned to user code instead a possible `Intl.canonicalizeLocaleList` function is a simple wrapper around CanonicalizeLocaleList to perform the necessary conversion from list to array. That's exactly the point of the algorithm steps in my previous mail. It also needs to be considered whether the duplicate removal in CanonicalizeLocaleList creates any issues for users of a potential `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function. Perhaps. Are there any cases you think of where removing duplicates would be a problem? I thought about use cases when a user assumes the i-th element of the output array is the canonicalised value of the i-th element in the input array. I can't tell whether this is a valid use case - I've only implemented ECMA-402, so I know a bit about the spec, but never actually used it in an application... Andy - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [syntax] arrow function notation is too greedy
On Thu, Jul 11, 2013 at 2:00 AM, Andrew Fedoniouk
news at terrainformatica.com https://mail.mozilla.org/listinfo/es-discuss
wrote:
/ Did we consider green gases emission increase that will happen due to that
// double parsing of code that currently is parsed strictly once?
//
// ( Consider that rhetoric question above as just a reminder that ES6
//parser will be used for existing web code when it will deployed for
//pretty much each connected machine and device ).
/
Hmm. Well, there is a lot of back and forth in those lines, so I'm not
sure what to make of them. Either the new features are wasteful or
they're not. Pick a position and quantify it. Let's have it out.
[...]
In the case of destructuring assignment, we don't rewind and do a
second parse, even if it *does* turn out that you're doing
destructuring assignment. We just have to re-interpret the AST for the
left-hand side that we just parsed as a left-hand side.
And it almost works [1] . ;-) But no worries, it will only get worse
when you add destructuring with defaults to the mix or the
CoverInitialisedName production. :-/
Like this `({a} = {}) = {}` or this `({a = {}} = {}) = {}` ...
- André
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=866624
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Automatically binding extracted methods
@@create allows you to set up instance prototypes, here's an amended version of your example code using ES6 classes: https://gist.github.com/anba/9f0acbb29bf755d26f37 The updated version also gets rid of the origProto workaround, but requires a custom @@hasInstance hook. I've tested the script with [1], not sure if the other ES6 runtimes/transpilers already provide support for @@create and @@hasInstance. - André [1] https://github.com/anba/es6draft Thanks to proxies now having a separate trap for invoke, we can automatically bind methods on get. I've written down my thoughts here: http://www.2ality.com/2013/06/auto-binding.html Axel -- Dr. Axel Rauschmayer axel at rauschma.de https://mail.mozilla.org/listinfo/es-discuss home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why can’t for-of be applied to iterators?
Just for the record:
Prototype lookup in ClassDefinitionEvaluation changed in draft rev. 14.,
so an API function should rather look like:
Mixin = (base, ...mixins) = mixins.reduce(Object.mixin, class extends
base {}.prototype).constructor
At least users now no longer need to access .prototype manually:
js class Foo { where(){ return Foo } }
js const BarMixin = { where(){ return BarMixin } }
js (new class extends Mixin(Foo) {}).where()
Foo
js (new class extends Mixin(Foo, BarMixin) {}).where()
BarMixin
- André
A tempest in a teapot. We can have better APIs that look nice for this
use-case. Develop some!
But let's not rush them into ES6, or invent custom syntax where API is
enough.
If someone does fast and good work, there's still time for ES6, or 7
(doesn't matter as much as the quality of the work; browsers are
prototyping parts of both).
/be
Dmitry Soshnikov wrote:
/
// On Jun 11, 2013, at 8:07 PM, Andrea Giammarchi wrote:
//
// if it's about being mature, then this is mature enough, if
// Object.mixin will be finalized:
//
// ```javascript
// class Bar extends [M1, M2, M3].reduce(
//Object.mixin,
//Object.create(Foo.prototype)
// ) {
//// class definition ...
// }
// ```
//
// I must admit that looks weird though ...
//
//
// Exactly - it might be really cool from the language abilities
// perspective, but from the end-users, the example is not that useful:
// if the language provides some abstraction (the class abstraction in
// this particular case), the users which will join to JS starting form
// ES6 will have complete right to not even know what that magic
// prototype mean -- the one which you expose outside actually breaking
// the class abstraction. The prototype chain is just the implementation
// detail now (and all implementation detail should be hidden in the
// best), not a feature.
//
// P.S.: and I still need to choose my English words better :) for the
// mature I probably more meant syntactically solid rather than a
// library method.
//
// But yeah, I promised not to do big off-topic in this for-of thread.
//
// Dmitry/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iteration protocol: a sentinel value?
The sentinel cannot carry a return value, from the notes:
DH: Mark's proposal is broken, because it doesn't work with return
values of generators.
MM: Agreed.
In the TC39 meeting notes, Mark suggested something similar (but more
sophisticated) which was rejected and I am wondering why.
Herman's protocol is (roughly):
- Values v: { value: v }
- After last value: { done: true }
With a sentinel value, this would look like:
- Values v: v
- After last value: SENTINEL_VALUE (defined once, somewhere)
The latter seems simpler to me -- what's wrong with it?
Thanks!
Axel
--
Dr. Axel Rauschmayer
axel at rauschma.de https://mail.mozilla.org/listinfo/es-discuss
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iteration protocol: a sentinel value?
`return expression` is allowed within a generator [1] and to be able
to retrieve the expression's value, a (possibly frozen) sentinel value
doesn't quite work.
A simple example:
function* gen() {
return 123;
}
var {value, done} = gen().next();
assertEq(done, true);
assertEq(value, 123);
[1] http://wiki.ecmascript.org/doku.php?id=harmony:generators#returning
On 5/14/2013 1:32 PM, Axel Rauschmayer wrote:
Thanks! Can you elaborate?
On May 14, 2013, at 9:20 , André Bargull andre.barg...@udo.edu
mailto:andre.barg...@udo.edu wrote:
The sentinel cannot carry a return value, from the notes:
DH: Mark's proposal is broken, because it doesn't work with return
values of generators.
MM: Agreed.
In the TC39 meeting notes, Mark suggested something similar (but more
sophisticated) which was rejected and I am wondering why.
Herman’s protocol is (roughly):
- Values v: { value: v }
- After last value: { done: true }
With a sentinel value, this would look like:
- Values v: v
- After last value: SENTINEL_VALUE (defined once, somewhere)
The latter seems simpler to me – what’s wrong with it?
--
Dr. Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de
home: rauschma.de http://rauschma.de
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: B.3.1 The __proto__ pseudo property
SpiderMonkey at least goes out of its way to do [[Set]] (let's call it)
not [[DefineOwnProperty]] for 'o = {__proto__: 42}', so why wouldn't
[[Set]] create a fresh property, seeing nothing on Object.prototype
named '__proto__' with a setter to run?
SpiderMonkey/JSC currently just use [[Set]] without any further checks,
i.e. when you re-define Object.prototype.__proto__, you're able to
interfere object creation which uses __proto__. Is this intentional?
js Object.defineProperty(Object.prototype, __proto__, {set:
function(){print(setter)}})
({})
js ({__proto__: null})
setter
({})
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Syntax error for lexical declarations not directly within block
Statements and Declarations are separate production rules (cf. 12 Statements and Declarations in the draft), only a Statement can be nested directly within an if-Statement. - André Hi, I've noted that it is a Syntax error to write things like `if (foo) let x;` or `while (bar) let x;` (without block enclosing the `let x` statement), both in the latest version of FF and Chrome (appropriate experimental flags enabled), which is a very reasonable behaviour. However, I was unable to find where (or if) that behaviour is defined in the current spec draft. Could you help? Thanks, —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: bugs.ecmascript.org database is slow today
It improved a bit, I've just added a new bug and the loading time was only one minute instead of two minutes. - André On 4/12/2013 3:21 AM, Brendan Eich wrote: I heard some db cleaning was just done -- any improvements? /be André Bargull wrote: A bit off topic: bugs.ecmascript.org is extremely slow today, when I file a new issue, the browser loads for about two minutes. And I even got multiple mid-air collision detection errors for my own (!) changes. Maybe someone can take a look and figure out what's going on there. (The search functionality is not affected.) Thanks, André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
bugs.ecmascript.org database is slow today
A bit off topic: bugs.ecmascript.org is extremely slow today, when I file a new issue, the browser loads for about two minutes. And I even got multiple mid-air collision detection errors for my own (!) changes. Maybe someone can take a look and figure out what's going on there. (The search functionality is not affected.) Thanks, André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions/issues regarding generators
/ The most significant change from the meeting (and it really wasn't
// explicit on the whiteboard) is that generator prototypes don't have a
// constructor property that links back to its generator function instance.
// In other words, you can't say:
//
// function * ofCollection() {for (i of collection) yield i};
// var itr1 = ofCollection();
// var itr2 = iter1.constructor(); //TypeError
//
//
// That wouldn't be a type error. It would be invoking the value of the
// inherited generator property.
//
/
Sorry, ...inherited *constructor* property that is.
But the inherited constructor property is not callable, so it's still a
TypeError:
js function * ofCollection() {for (let i of collection) yield i}; js
var itr1 = ofCollection(); js var itr2 = itr1.constructor(); uncaught
exception: TypeError: object is not a function
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Two different use cases for privacy?
The function for use case #1 seems to be Object.getOwnPropertyKeys() [15.2.3.15]: js Object.keys(Array) [] js Object.getOwnPropertyNames(Array) [length,name,prototype,isArray,of,from,caller,arguments] js [for (x of Object.getOwnPropertyKeys(Array)) x] [length,name,prototype,isArray,of,@@create,from,caller,arguments] It seems to me that there are two different use cases for privacy: Use case 1: Hide some properties from the outside (when listing properties or getting expansion help from an IDE). Many people use a naming convention here (e.g. a prefixed underscore). This hiding does not have to be completely safe. There could be methods that list all property keys, even hidden ones. Hiding is more like a hint (you don't normally need to look at this) than actual protection. Use case 2: Keep data completely safe inside an object. #1 is very similar to the [[Enumerable]] attribute (if it was used slightly differently and more consistently). Symbols already almost serve this use case, because they are hidden from current ways of listing property keys. But you don't want to hide some of the public symbols such as @@create. Hence, all that would be needed would be a flag, as a hint for IDEs and functions that list property keys. #2 could be handled via WeakMap. Do I see this correctly? -- Dr. Axel Rauschmayer axel at rauschma.de https://mail.mozilla.org/listinfo/es-discuss home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Upcoming talk on ES6 in Russia
On March 30, I'll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to. A draft of my slides is here, feedback welcome: http://dl.2ality.com/codefest_es6.pdf [1]http://2013.codefest.ru/ -- Dr. Axel Rauschmayer axel at rauschma.de https://mail.mozilla.org/listinfo/es-discuss home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com Two minor comments/questions: Slide 24: Per draft rev14, super references in method definitions within object literals are not allowed (cf. page 117). Did this change recently? And a missing comma after the __proto__ entry. Slide 36: Unless there is an @@iterator on Object.prototype, the first for-of loop doesn't quite work. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
The incompatibility you've noticed is just a spec bug in
[[HasIntegrity]]. In step 2a of 8.3.3, the value of [[Extensible]] needs
to be inverted. With that change applied, the code snippet will return
`true`.
- André
Hi,
Allen's latest draft (Rev. 14) contains the change where
[[Freeze]],[[Seal]] and [[PreventExtensions]] have been consolidated into
[[HasIntegrity]]/[[SetIntegrity]]. While no changes were made to the Proxy
API (i.e. no has/getIntegrity traps yet), the definition of
Object.{freeze,seal,preventExtensions} did change, and this is sufficient
to expose an incompatibility with ES5, namely:
Object.isFrozen(Object.preventExtensions({})) // true in ES5, false in ES6
Rev14 draft
I still feel like the consolidation isn't worth this incompatibility.
Allen, could you clarify what your intent is? Is it your intent that this
incompatibility will be fixed with further spec changes?
Cheers,
Tom
2013/2/21 Brendan Eich brendan at mozilla.com
https://mail.mozilla.org/listinfo/es-discuss
/ Tom Van Cutsem wrote:
//
// That said, I don't think this is enough evidence either for or against
// the breaking change.
//
//
// I have a hard time believing we can break ES5. It has been shipping for
// years (plural, at least in one case) in major browsers that evergreen their
// user bases.
//
// /be
/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Invalid Octal Escapes in Regular Expressions
Thanks for your answer, then I'm looking forward to the meeting results. - André PS: Here's another difference, /^\$/ matches \0 in SM, JSC and Opera, whereas in IE10 and V8 it matches \u0 (that's \0 concat'ed with 0). Per [2] it ought to be \u0. On 3/16/2012 2:05 AM, Luke Hoban wrote: Although not specified in ES5, octal escapes are required in regular expressions for web reality [1,2]. [1] even claims the extensions are extensive and consistent across browsers. But for invalid octal escapes, the browsers are not consistent. For example: /^\8$/ matches \\8 in Spidermonkey, JSC and Opera, whereas in IE10 and V8, /^\8$/ matches 8. /^\777$/ matches \x3F7 in SM, JSC, Opera and V8, whereas in IE10, /^\777$/ matches \u01FF. Is there going to be any kind of consolidation for ES6? Yes - the goal of [1] and [2] is to include normative optional text in Annex B of ES6 which nails down more of the behavior. The spec text in [2] was an attempt to describe the shared common ground. From your examples, it looks like there remain places where there are disagreements between browsers even in the limited extension this spec text aims to cover. I'll put discussion of [2] on the agenda for the upcoming TC39 f2f meeting. For reference - that candidate spec text gives the following behavior for your two examples: /^\8$/ matches 8. It is treated as an IdentityEscape because it is not a valid DecimalEscape or OctalEscapeSequence. /^\777$/ matches \x3F7. It is treated as an OctalEscapeSequence followed by a 7. Luke [1] http://wiki.ecmascript.org/doku.php?id=harmony:regexp_match_web_reality [2] http://wiki.ecmascript.org/doku.php?id=strawman:match_web_reality_spec ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Invalid Octal Escapes in Regular Expressions
Although not specified in ES5, octal escapes are required in regular expressions for web reality [1,2]. [1] even claims the extensions are extensive and consistent across browsers. But for invalid octal escapes, the browsers are not consistent. For example: /^\8$/ matches \\8 in Spidermonkey, JSC and Opera, whereas in IE10 and V8, /^\8$/ matches 8. /^\777$/ matches \x3F7 in SM, JSC, Opera and V8, whereas in IE10, /^\777$/ matches \u01FF. Is there going to be any kind of consolidation for ES6? Thanks, André [1] http://wiki.ecmascript.org/doku.php?id=harmony:regexp_match_web_reality [2] http://wiki.ecmascript.org/doku.php?id=strawman:match_web_reality_spec ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mailing list reminder: password is sent in the clear
Log-in at [1] and remove the option to send a monthly password remainder? *Get password reminder email for this list?* Once a month, you will get an email containing a password reminder for every list at this host to which you are subscribed. You can turn this off on a per-list basis by selecting /No/ for this option. If you turn off password reminders for all the lists you are subscribed to, no reminder email will be sent to you. [1] https://mail.mozilla.org/options/es-discuss Can this be fixed? I've already sent feedback, but didn't get a response. Preferably, passwords would also be encrypted for storage. -- Dr. Axel Rauschmayer axel at rauschma.de https://mail.mozilla.org/listinfo/es-discuss twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: do-while grammar
Just for the record, here's a link to the bug report on bugzilla
concerning ASI for do-while:
https://bugzilla.mozilla.org/show_bug.cgi?id=238945
(Interesting that I came across the very same issue in January while
working on the OpenLaszlo parser code :-)
FWIW, JavaScriptCore provides automatic semicolon insertion after all
do-while statements in all contexts. We made this change for web
compatibility, mimicking a Firefox quirk.
Geoff
On Feb 8, 2011, at 11:53 AM, Dave Fugate wrote:
Just to confirm, do-while iteration statements do in fact require a
semi-colon at the end as indicated in 12.6.1 of ES5, correct? That
is, a production of the nature:
do {;} while (false)*false*;
would be invalid JavaScript as doesn't meet any of the three rules set
out in 7.9.1, right?
Thanks,
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen's lambda syntax proposal
My example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax error, but it also (unfortunately) doesn't contain a
lambda expression. Or am I missing something?
Or a bit more obvious than the use of the comma-operator:
As soon as named lambdas are introduced (the weak spot on the \
proposal), you'll get big problems with the ^ proposal, too.
Consider the following snippet which is valid Javascript code, but
certainly not a lambda expression.
var f = function (){return 8;}
var x = 5
^f(x) { x=x*x }
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
