Also let's not forget that the WindowProxy behavior contradicts the JS
object model in that the non-configurable 'something' own property of the
window proxy is removed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/
As a follow up on my previous mixin proposal and the discussion at (
https://esdiscuss.org/topic/definition-mixins) I published a mixin library
on npm: smart-mix (https://www.npmjs.com/package/smart-mix).
It:
- mixes in public methods
- mixes in private methods
- allows sharing private state and p
Traditional function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
This is an illustration of the current `Promise.prototype.finally`
deficiency. In this example, the `incr` method does 2 things. It increases
`count` by 1. And increases `methodCallsCount` by 1. At a later point in
time, it was decided to add an `incr3` method that did the same, but
increase `count
I made the PR on the ecma repo so that the diff is smaller (since I'm
touching more sections than the proposal repo had).
https://github.com/tc39/ecma262/pull/1118/files
On Sun, Feb 25, 2018 at 5:27 AM, Jordan Harband wrote:
> Simply theorizing about how it might be done - without an actual spec
Trying better formatting for esdiscuss.org.
```
CreateResolvingFunctions(promise, finallySourcePromise)
update step 3: Let resolve be CreateBuiltinFunction(stepsResolve, «
[[Promise]], [[AlreadyResolved]], [[FinallySourcePromise]] »).
insert new step 6: Set resolve.[[FinallySourcePromise]] to
If TC39 finds a better solution than the existing one in good time, I don't
think it makes sense for it to wait for another year to implement it while
having a broken `Promise.prototype.finally` in the browsers.
I've been thinking about a solution and, if my solution is correct, the
changes are ve
In other words
```js
Promise.resolve().finally(() => {}).then(() => { console.log(1); });
Promise.resolve().then(() => {}).then(() => { console.log(2); }).then(() =>
{ console.log(3); });
```
prints 2, then 3, then 1.
___
es-discuss mailing list
es-disc
@Ben Newman
There are 2 extra ticks, not just 1. The first one is caused by step 8
of 25.6.5.3.1 and the other one is caused by the fact that the
`thenFinally` callback passed in step 7 of 25.6.5.3 returns a promise. I'm
wondering if this trade-off is the right one.
erministic ordering between the `console.log` statements. Are you
> suggesting that
> such a deterministic ordering should be imposed by using micro tasks or
> what are you
> proposing here exactly?
>
> In other words, why exactly do you expect the result to always be printing
> 1 be
I find it weird that
```js
Promise.resolve().finally(() => {}).then(() => { console.log(1); });
Promise.resolve().then(() => {}).then(() => { console.log(2); });
```
prints 2 and then 1. It would have been possible to spec it in such a way
that it would have printed 1 and 2.
On the other hand
`
Note that if you want to use the Proxy that way you will probably want to
implement the setPrototypeOf and preventExtensions traps as well since,
together with set, defineProperty and deleteProperty, they are the traps
whose associated internal methods can have side effects on the target when
the t
On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote:
>
>
> For example, I did a quick test comparing `[1, 2]` and `new Array(1, 2)`
> and found that performance was identical, in spite of the claimed
> inefficiency supposedly introduced by the need to look up `Array`.
>
>
I'm curious how you did that
On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote:
>
>
> With regard to the issue of the empty object inheriting a setter, my we're
> really clutching at straws here.
>
>
Really? I was simply informing you that `Object.assign({}, a, b)` is not
equivalent to `{...a, ...b}`.
_
Bob, it's not clear that you understood what Alexander said about the
lookup. Object.assign contains 2 names. 'Object' needs to be looked up in
all the execution contexts chain, starting with the current execution
context, until the global Object function is found. Then the 'assign'
property must b
A month ago I opened a github issue (
https://github.com/tc39/ecma262/issues/1061) in which I asked whether or
not TC39 should have a policy WRT the time frame in which a PR should be
merged. I mentioned that there was currently an open PR (
https://github.com/tc39/ecma262/pull/666) which had conse
>
>
> -- Forwarded message --
> From: dante federici
> To: es-discuss@mozilla.org
> Cc:
> Bcc:
> Date: Mon, 27 Nov 2017 22:22:11 +
> Subject: Re: Re: Definition mixins
> I'm having a little trouble parsing your proposed syntax. Can you
> formalize it a bit better? Am I write in
On Sat, Nov 18, 2017 at 7:53 PM, Bob Myers wrote:
> I'm a JS programmer with more decades of experience than I care to
> mention, and follow developments in language design closely. Frankly, I
> don't understand what you are trying to accomplish or why support for it
> needs to be in the language
On Sat, Nov 18, 2017 at 7:19 PM, Isiah Meadows
wrote:
> Protocols are not mixins - they're interfaces. They specify minimum
> behavior required to implement (their primary focus), not simply extended
> behavior. In particular, protocols and mixins would be more complementary
> than conflicting.
>
I updated the proposal with sections for motivation, comparison with other
kinds of mixins and protocols.
https://github.com/raulsebastianmihaila/ecma262-definition-mixins-proposal
The protocols, in their current form, are a naive kind of mixin
imlementation. I think it's better to separate contra
I need to reword one phrase I wrote: I haven't seen a mixin approach in
Javascript similar to this approach or one that doesn't have at least some
of the issues I listed in the beginning of this thread and I think it's
important to be aware of this when balancing out mixins.
___
On Mon, Nov 13, 2017 at 4:25 PM, T.J. Crowder wrote:
>
> There's an Edit link on messages on esdiscuss.org to let you fix issues
> like that (e.g., when there's some esdiscuss.org-specific issue).
>
Cool, thanks!
On Mon, Nov 13, 2017 at 4:48 PM, Isiah Meadows
wrote:
> May I point out a few thi
The first version is based a hundred percent on concepts and mechanisms
already used in Ecma262. (Looks like esdiscuss.org has an issue with
percentages).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
For some reason, esdiscuss.org doesn't render my last sentence entirely.
This is what I wrote:
Did you take a look at the spec I provided? The first version is based 100%
on concepts and mechanisms already used in Ecma262.
___
es-discuss mailing list
es-
On Mon, Nov 13, 2017 at 1:54 PM, Bob Myers wrote:
> You should review the TypeScript approach to mixins:
> https://www.typescriptlang.org/docs/handbook/mixins.html.
>
This seems very similar to the naive approach based on Object.assign that I
mention in the first message of this thread. Please s
On Mon, Nov 13, 2017 at 10:54 AM, T.J. Crowder wrote:
>
>
> Could you add a "Motivations" section outlining why this is needed and
> what alternatives currently exist without new syntax?
>
>
It would be indeed worth adding such a section in the proposal, but for now
please take a look at the first
I wrote a first draft of the spec for the proposal (
https://github.com/raulsebastianmihaila/ecma262-definition-mixins-proposal).
In some cases I'm not certain about the accuracy of the spec and I also cut
the corners in a few places. There are 2 versions. The second version only
contains the diffe
On Sun, Nov 5, 2017 at 5:27 PM, kai zhu wrote:
> the problem is that you chose to write the chess program in
> javascript, instead of say, python or c#.
>
Kai, you're off-topic. The topic is mixins, not chess games. Please refrain
from disrupting this thread.
Actually the mix obj must be extensible but must be an exotic object so
that it's extended only through the mixin mechanism.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Also, in the same context, for different mixin associated objects there
will be different mix objects:
```js
function F() {
const obj = {};
const obj2 = {};
mixin obj, mixin1;
mixin obj2, mixin2;
}
function mixin1() {
return (obj, mix) => {};
}
function mixin2() {
return (obj, mix)
One issue that just occurred to me is that we want different families of
mixin functions to have access to different mix objects, so that one family
doesn't have access to mixin functions from another family (since they're
private and the constructor must decide what private data shares with the
mi
I've been successfully experimenting with a kind of mixins which is
different from the naive mixin solution (for instance based on
Object.assign) and from functional mixins (
https://medium.com/javascript-scene/functional-mixins-composing-software-ffb66d5e731c).
I call them definition mixins.
The
I'd like to propose the following syntax:
```js
const obj = {
x:| 3, // non-writable property with value 3
y:] 4, // non-configurable property with value 4
z:} 5 // non-writable non-configurable property with value 5
};
```
Perhaps class fields could also use this syntax. Maybe decorators c
On Tue, Apr 25, 2017 at 12:15 AM, Tab Atkins Jr.
wrote:
>
> The obvious question is, why do you want to use `this`?
>
> ~TJ
>
For cases such as a debounce function:
```js
const debounce = (func, delay) => {
let timeout;
return function (...args) {
clearTimeout(timeout);
I have a dilemma. I like how typically the built-in methods are not
constructors (like Array.prototype.forEach). I have cases in which I'm
creating a function in which I want to use `this` but I would like the
function to not be constructible. There are ways of doing this:
- checking new.target - b
If the module that holds the secrets knows how to import the modules that
it wants to share the secret with, it can import a certain function from
them to share the secret by calling that function and pass the secret.
___
es-discuss mailing list
es-discus
To be more explicit, the invariants allow this surprising behavior:
```js
Object.preventExtensions(nonStandardExoticObject);
Object.isExtensible(nonStandardExoticObject); // false
'foo' in nonStandardExoticObject; // false
Object.getOwnPropertyDescriptor(nonStandardExoticObject, 'foo'); // {valu
If it's not obvious how the state of the target can be checked in order to
enforce the invariant, it can be checked as it is checked for all the other
invariants, namely in the internal method (in our case the [[HasProperty]]
internal method) of the proxy, after the hook (in our case the `has` hook
By the time [[HasProperty]] (and `"foo" in p`) finishes, the property
doesn't exist anymore, therefore this invariant is not enforced. The
invariant is: if the property *exists* and the object is non-extensible,
[[HasProperty]] must return true. So, there's no guarantee it returns true
if you've de
On Sun, Mar 5, 2017 at 2:52 PM, Oriol _ wrote:
>
> delete obj.foo;
>
>
When you delete the property of an ordinary object, it stops being 'an
observable own property using [[GetOwnProperty]]'. So,
`Object.getOwnPropertyDescriptor(obj, "foo")` returns undefined afterwards.
Wouldn't it make sense to have the following [[HasProperty]] invariant for
all the objects?
If the object is non-extensible and P is an observable own property
using [[GetOwnProperty]], [[HasProperty]] must return true.
The same rule applies for [[OwnPropertyKeys]], where the resulted List must
c
In your example there are 7 promises.
1) `p`
2) `Promise.resolve(console.log('A'))`
3) the promise returned by the first `then` call
4) `Promise.resolve(console.log('B'))`
5) the promise returned by the second `then` call
6) Promise.resolve(console.log('C'))
7) the promise returned by the third `t
On Thu, Feb 9, 2017 at 4:41 PM, Romuald Quantin wrote:
> Usually solved this way:
>
> - export something to instantiate (a function or a class)
>
> ```
> module.exports = MyClass;
> ```
> - export an object (will be shared, only one instance)
>
> ```
> module.exports = {};
> ```
> - export a new
1) My understanding is that a module is a singleton. But how does the spec
enforce that? Section 15.2.1.17 HostResolveImportedModule (
https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule) says that
the resolving process of a module must be indempotent. 'Each time it is
called with a speci
Can anybody share notes from the January meeting please? Thanks!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://tc39.github.io/ecma262/#sec-object-internal-methods-and-internal-slots
The actual semantics of objects, in ECMAScript, are specified via
algorithms called internal methods. Each object in an ECMAScript engine is
associated with a set of internal methods that defines its runtime
behaviour.
I disagree regarding the conformance. According to the conformance section (
https://tc39.github.io/ecma262/#sec-conformance):
A conforming implementation of ECMAScript may provide additional types,
values, objects, properties, and functions beyond those described in this
specification. In particu
Do you mean that an implementation is allowed to return an exotic object
from the Error constructor?
https://tc39.github.io/ecma262/#sec-error-message
The Error constructor calls OrdinaryCreateFromConstructor in step 2.
https://tc39.github.io/ecma262/#sec-ordinarycreatefromconstructor
According
and many of them aren't.
>
> On Fri, Jan 6, 2017, 14:58 Raul-Sebastian Mihăilă
> wrote:
>
>> That sounds like a bug because error objects are ordinary objects and the
>> [[GetOwnProperty]] internal method of ordinary objects doesn't have side
>> effects.
>&
That sounds like a bug because error objects are ordinary objects and the
[[GetOwnProperty]] internal method of ordinary objects doesn't have side
effects.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I agree, but note that a resolved promise is not the same as a fulfilled
promise (https://tc39.github.io/ecma262/#sec-promise-objects).
On Thu, Dec 29, 2016 at 11:40 AM, Jordan Harband wrote:
> You'd need to wrap the body of your `open` function in a try/finally, and
> do the `fsp.close` in the
Such a protocol would make sense only if new specific syntax was added to
the language. But is that really necessary when this can be implemented
very easily without new syntax?
```js
async function open(file, opts, func) {
const fd = await fsp.open(file, opts);
await func(fd);
await fsp.cl
On Wed, Oct 26, 2016 at 10:25 AM, Olivier Lalonde
wrote:
> I don't think so, what do you mean?
>
Conceptually, await is similar to Promise.resolve and this similarity is
more useful than saving a few keystrokes.
___
es-discuss mailing list
es-discuss@m
Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Note that `["__proto__"]` is different from `__proto__`, while
`"__proto__"` is the same as `__proto__`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
How is NaN useful? Isn't it better to be explicit if you really want a
string?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Disregard my reply as it doesn't make sense. :-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Step 4 of
http://www.ecma-international.org/ecma-262/7.0/index.html#sec-json.parse
says that `__proto__` shouldn't have special meaning when parsing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
In depends on what observing means. In this "inception" kind of observing,
you could argue that the property hasn't yet been observed because [[Get]]
was called before.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/e
A relevant github issue regarding [[OwnPropertyKeys]] is
https://github.com/tc39/ecma262/issues/461 . I also
wish [[OwnPropertyKeys]] didn't allow duplicates.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Claude, I don't see how non-extensibility and deleting properties are
connected.
> ```js
> var target = Object.preventExtensions({ x: 1 })
> var proxy = new Proxy(target, {
> deleteProperty() { return true }
> })
>
> Object.isExtensible(proxy) // false
> delete proxy.x // true
> proxy.hasOwnP
e.
>
> With this change, the call to SetIntegrityLevel ends with a call to
> TestIntegrityLevel, which will notice that O is in fact not frozen and thus
> cause the call to Object.freeze to fail.
>
> To summarize: the error here is not with the proxy invariant checks (the
> proxy i
Initially posted on github (https://github.com/tc39/ecma262/issues/652),
but I think the mailing list is more appropriate.
Usually methods on Object that change some internal state of the
objects/properties of the objects either succeed or throw. However,
Object.freeze can fail to freeze proxies w
Indeed, according to
http://www.ecma-international.org/ecma-262/7.0/index.html#sec-functionallocate,
generators don't have the [[Construct]] internal method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I wasn't suggesting any mechanism for accomplishing that. Method borrowing
is error prone either way. With the current spec, it's risky because this
and super basically may use two different prototype chains. Also you may
change the prototype of the home object and run into trouble. (In the
alterna
An alternative would be to consider the object where the method key was
found as the home object of the method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I see that es7 is now a standard.
http://www.ecma-international.org/ecma-262/7.0/index.html
Congratulations!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I don't think it was related to nesting. Anyway, I wrote to him something
similar to what I wrote here and later he agreed. Thanks for confirming.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Douglas Crockford said that eventually JSLint would require exports at the
top of the file. However I think there are some issues.
If my understanding is correct,
```js
export default myConst;
const myConst = {};
```
would throw because when the export is evaluated, in step 2 of the
Evaluation a
Has anybody managed to take meeting notes during the last meeting? If so,
can they please share them? Thank you!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Wouldn't it be enough to prevent access from normal SES realms to the
proto-SES realm's Zone primordial in order to keep SES as an ocap
environment (by having the global objects from normal SES realms inherit
from a proxy of the global object from proto-SES, instead of inheriting
directly from the
Bradley, your example throws an error because `this` is uninitialised when
the arrow function is called. (Checked in Firefox).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
But note that `this` is not a primitive (not even in base constructors). So
if a base constructor syntactically returns a primitive, it will
semantically return its `this` value, which is an object. So the `this`
value will be an object in the derived constructor as well.
__
The rule is that derived constructors throw if they return a primitive
different from undefined, so these throw.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Yes, both do.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
None does.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
en't intended to be value type factories, so I find this
> unlikely to change.
>
> On Tue, Mar 8, 2016, 15:46 Raul-Sebastian Mihăilă
> wrote:
>
>> I see that in step 13 of the [[Construct]] method of ordinary functions (
>> https://tc39.github.io/ecma262/#sec-ecmasc
I see that in step 13 of the [[Construct]] method of ordinary functions (
https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-construct-argumentslist-newtarget),
the value resulted from the evaluation of the function body is checked and
if the constructor is a derived constructor, the v
Forgot about instanceof.
```
var x = 0;
function Foo() {
if (new.target) {
this.i = 0;
} else {
// I don't know what class.instance is supposed to mean.
return x++;
}
}
Object.setPrototypeOf(Foo, null);
Foo[Symbol.hasInstance] = () => false;
```
__
It seems to me that you are mixing Foo and f. If that's not intended then
what you want can be obtained with:
```
var x = 0;
function Foo() {
if (new.target) {
this.i = 0;
} else {
// I don't know what class.instance is supposed to mean.
return x++;
}
}
Object.setPrototypeOf(Foo, null);
```
All
@Benjamin: Your example is different than Bradley's. Should be:
```
var r1, p1 = new Promise(r => r1 = r);
var r2, p2 = new Promise(r => r2 = r);
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
When I first read that part of the spec, my understanding was that the two
promises would cancel each other out by waiting for each other, but without
performing an infinite set of PromiseJobs. The resolving functions created
in step 1 of 25.4.2.2 that are set as reactions for the other promise are
Done, thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I would file a bug, but I forgot my bugzilla password and bugzilla doesn't
send me the email to reset the password.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
If apply (
http://www.ecma-international.org/ecma-262/6.0/#sec-function.prototype.apply)
is called with no argArray, PrepareForTailCall is not performed, unlike in
Function.prototype.call, where PrepareForTailCall is always performed. Is
it not needed or is it a bug?
___
Actually I may have misunderstood. I guess you want held to be false in the
yielding context.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
To Andrea:
A function like the one you describe would be practical only if, when
called in a sync context, it could wait by blocking, unlike when being
called in an async context. Otherwise, it doesn't work:
```
let theValue;
function fetchTheValue() {
return fetch('/theValue')
.then
In 9.1.11. it's specified that the iterator returned by the [[Enumerate]]
method iterates over String-valued keys. But the informative definition at
the end of 9.1.11. is based on whatever is returned by calling
Reflect.enumerate on the prototype of the current object, assuming that
there is such a
What is the reason for not enforcing invariants on the enumerate trap with
respect to non-configurable, enumerable, own properties of (non-extensible)
targets? More explicit: why is there no error thrown if such a property is
not yielded by the iterator that is returned from the enumerate trap? Is
89 matches
Mail list logo