Proposal to add EventEmitter to core [ES7]
Hi, I propose the inclusion of the node/io EventEmitter class[1] in core targeting ES7. Reasoning: The .on/.emit model is very popular[2] in the ECMAScript land, and it suits the language a lot. We use events pretty much everywhere in the JS land. It makes sense for the standard EventEmitter class used commonly to be included in core. With ES6 classes, userland code classes extending[3] the EventEmitter class would be pretty common and useful even in environments like browsers. Notes: I think the `.once` method from the node/io EventEmitter class _could_ be left out from standard implementation mainly because we would rather use Promises there. Although it would also make sense to keep it in for further compatibility. [1] https://iojs.org/api/events.html [2] https://github.com/search?l=JavaScriptq=eventemitterref=opensearchtype=Code [3] https://github.com/search?p=2q=extends+eventemitterref=searchresultstype=Codeutf8=%E2%9C%93 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
import ModuleSpecifier
I was under the impression that the following is a valid import statement:
import {something} from './somefile';
I know this used to work in Traceur. However, in the latest version of
Traceur I have to include a file extension like this for it to work:
import {something} from './somefile.js';
I don't see any place in the spec. where it describes whether
ModuleSpecifier should include a file extension. Maybe I just missed it. Is
Traceur correct to require it?
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maybe we need a reflect API to iterate over instance members
Not exactly
Reflect.ownKeys does not walk up prototype chain so it does not return
inherited members
Reflect.enumerate seems not return non-enumerable members
What I propose is an API that returns both non-enumerable and inherited members
Best regards
Gray Zhang
在 2015年6月1日 上午1:15:58, Zhang,Lili(PAPE) (zhanglil...@baidu.com) 写到:
Not exactly
Reflect.ownKeys does not walk up prototype chain so it does not return
inherited members
Reflect.enumerate seems not return non-enumerable members
What I propose is an API that returns both non-enumerable and inherited members
UBFT 张立理
Hi int08h ☎ 18621600455
在 2015年6月1日 上午12:44:52, Harband Jordan (ljh...@gmail.com) 写到:
Would `Reflect.ownKeys` or `Reflect.enumerate` help you here?
On Sun, May 31, 2015 at 4:42 AM, Gray Zhang otakus...@icloud.com wrote:
Since class’s members are non-enumerable by default (which is a good choice) we
cannot use for .. in to iterate over all members of an instance, the same
problem could exists in a plain object when we use Object.defineProperty API.
In real world there are some scenarios where we need to iterate over members, A
common example is we need to find all set{SomeThing} methods so we can do an
auto dependency injection.
Certainly we can write a 3rd-party function to find all members through
prototype chain:
function getAllMembersKeys(obj) {
let keys = [];
while (obj) {
keys.push(...Object.getOwnPropertyNames(obj));
obj = Object.getPrototypeOf(obj);
}
return keys;
}
But it doesn’t look nice and lacks considerations of many things such as
Symbol’d keys.
Look around other languages with reflection API, most of them would provide a
method to iterate over all members / properties / methods of an instance, so
why not we provide a set of utility API:
Reflect.getAllMembersNames
Reflect.getAllMemberDescriptors
Reflect.getAllMethodNames
Reflect.getAllMethodDescriptors
Reflect.getAllPropertyNames
Reflect.getAllPropertyDescriptors
Best regards
Gray Zhang
___
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
Re: Maybe we need a reflect API to iterate over instance members
Would `Reflect.ownKeys` or `Reflect.enumerate` help you here?
On Sun, May 31, 2015 at 4:42 AM, Gray Zhang otakus...@icloud.com wrote:
Since class’s members are non-enumerable by default (which is a good
choice) we cannot use for .. in to iterate over all members of an
instance, the same problem could exists in a plain object when we use
Object.defineProperty API.
In real world there are some scenarios where we need to iterate over
members, A common example is we need to find all set{SomeThing} methods
so we can do an auto dependency injection.
Certainly we can write a 3rd-party function to find all members through
prototype chain:
function getAllMembersKeys(obj) {
let keys = [];
while (obj) {
keys.push(...Object.getOwnPropertyNames(obj));
obj = Object.getPrototypeOf(obj);
}
return keys;
}
But it doesn’t look nice and lacks considerations of many things such as
Symbol’d keys.
Look around other languages with reflection API, most of them would
provide a method to iterate over all members / properties / methods of an
instance, so why not we provide a set of utility API:
- Reflect.getAllMembersNames
- Reflect.getAllMemberDescriptors
- Reflect.getAllMethodNames
- Reflect.getAllMethodDescriptors
- Reflect.getAllPropertyNames
- Reflect.getAllPropertyDescriptors
--
Best regards
Gray Zhang
___
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
Re: 2 questions about ES6 module loaders
Glen wrote: PS. from X import Y syntax would have been useful in cases where IDEs provide auto-completion. I know it's too late for changes now. It has other advantages: Python-like for those who care; Y can be a long braced list or pattern, which goes better at the end. But too late, and import was reserved in ES1 and ur-JS, but not in IE JScript (which did not follow ES1's list of future reserved words, reserving only class enum extends super, IIRC). Still, some warding-off effect from the '90s when people couldn't use `import` as an identifier. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: import ModuleSpecifier
It is syntactically valid, but there is no specification for what the module
specifier string should contain. Traceur has one rule, and if you’re using
Traceur you need to follow Traceur’s rules. I’m sure other transpilers have
their own chosen rules.
In a hypothetical future where browsers have a module loader, they will have
their own rule. Similarly, io.js will have its own.
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark
Volkmann
Sent: Sunday, May 31, 2015 17:21
To: es-discuss@mozilla.org
Subject: import ModuleSpecifier
I was under the impression that the following is a valid import statement:
import {something} from './somefile';
I know this used to work in Traceur. However, in the latest version of Traceur
I have to include a file extension like this for it to work:
import {something} from './somefile.js';
I don't see any place in the spec. where it describes whether ModuleSpecifier
should include a file extension. Maybe I just missed it. Is Traceur correct to
require it?
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: import ModuleSpecifier
Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called into doubt, even as part of a hypothetical future :-|. (Is there another kind? :-P) /be Domenic Denicola wrote: Yes, in theory. However, browsers are more likely to wait until there’s a standard for browser module loaders before shipping modules, in order to avoid such divergent behavior. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: import ModuleSpecifier
Are you saying that in the future each browser can have its own rule for
module specifier strings?
On Sun, May 31, 2015 at 4:31 PM, Domenic Denicola d...@domenic.me wrote:
It is syntactically valid, but there is no specification for what the
module specifier string should contain. Traceur has one rule, and if you’re
using Traceur you need to follow Traceur’s rules. I’m sure other
transpilers have their own chosen rules.
In a hypothetical future where browsers have a module loader, they will
have their own rule. Similarly, io.js will have its own.
*From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Mark
Volkmann
*Sent:* Sunday, May 31, 2015 17:21
*To:* es-discuss@mozilla.org
*Subject:* import ModuleSpecifier
I was under the impression that the following is a valid import statement:
import {something} from './somefile';
I know this used to work in Traceur. However, in the latest version of
Traceur I have to include a file extension like this for it to work:
import {something} from './somefile.js';
I don't see any place in the spec. where it describes whether
ModuleSpecifier should include a file extension. Maybe I just missed it. Is
Traceur correct to require it?
--
R. Mark Volkmann
Object Computing, Inc.
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: import ModuleSpecifier
Yes, in theory. However, browsers are more likely to wait until there’s a
standard for browser module loaders before shipping modules, in order to avoid
such divergent behavior.
But, I doubt that io.js, Traceur, etc. will follow the browser-loader standard.
For example io.js will likely have a loader that is more in line with their
current ES5 one, and transpilers will probably contain a way of switching
between io.js and browser behaviors, at the bare minimum.
From: Mark Volkmann [mailto:r.mark.volkm...@gmail.com]
Sent: Sunday, May 31, 2015 19:37
To: Domenic Denicola
Cc: es-discuss@mozilla.org
Subject: Re: import ModuleSpecifier
Are you saying that in the future each browser can have its own rule for module
specifier strings?
On Sun, May 31, 2015 at 4:31 PM, Domenic Denicola
d...@domenic.memailto:d...@domenic.me wrote:
It is syntactically valid, but there is no specification for what the module
specifier string should contain. Traceur has one rule, and if you’re using
Traceur you need to follow Traceur’s rules. I’m sure other transpilers have
their own chosen rules.
In a hypothetical future where browsers have a module loader, they will have
their own rule. Similarly, io.js will have its own.
From: es-discuss
[mailto:es-discuss-boun...@mozilla.orgmailto:es-discuss-boun...@mozilla.org]
On Behalf Of Mark Volkmann
Sent: Sunday, May 31, 2015 17:21
To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: import ModuleSpecifier
I was under the impression that the following is a valid import statement:
import {something} from './somefile';
I know this used to work in Traceur. However, in the latest version of Traceur
I have to include a file extension like this for it to work:
import {something} from './somefile.js';
I don't see any place in the spec. where it describes whether ModuleSpecifier
should include a file extension. Maybe I just missed it. Is Traceur correct to
require it?
--
R. Mark Volkmann
Object Computing, Inc.
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maybe we need a reflect API to iterate over instance members
Forgive me for golfing it, but
function getAllPropertyNames(o) {
if (!o) return [];
return Object.getOwnPropertyNames(o) +
getAllPropertyNames(Object.getPrototypeOf(o));
}
or as a generator
function* allPropertyNames(o) {
if (!o) return;
yield* Object.getOwnPropertyNames(o);
yield* allPropertyNames(Object.getPrototypeOf(o));
}
don't seem too onerous.
Though on the other hand, didn't I hear that prototype loops are now
possible with Proxies? If so, then you'd need to handle that.
Then again, if you're going to handle weird cases, then what should it
even return if you go through a Proxy's getPrototypeOf trap that mutates
the set of properties?
On 05/31/2015 04:42 AM, Gray Zhang wrote:
Since class’s members are non-enumerable by default (which is a good
choice) we cannot use |for .. in| to iterate over all members of an
instance, the same problem could exists in a plain object when we use
|Object.defineProperty| API.
In real world there are some scenarios where we need to iterate over
members, A common example is we need to find all |set{SomeThing}|
methods so we can do an auto dependency injection.
Certainly we can write a 3rd-party function to find all members
through prototype chain:
|function getAllMembersKeys(obj) {
let keys = [];
while (obj) {
keys.push(...Object.getOwnPropertyNames(obj));
obj = Object.getPrototypeOf(obj);
}
return keys;
}
|
But it doesn’t look nice and lacks considerations of many things such
as Symbol’d keys.
Look around other languages with reflection API, most of them would
provide a method to iterate over all members / properties / methods of
an instance, so why not we provide a set of utility API:
* |Reflect.getAllMembersNames|
* |Reflect.getAllMemberDescriptors|
* |Reflect.getAllMethodNames|
* |Reflect.getAllMethodDescriptors|
* |Reflect.getAllPropertyNames|
* |Reflect.getAllPropertyDescriptors|
Best regards
Gray Zhang
___
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
Re: 2 questions about ES6 module loaders
What's the reason for this? With something like PJAX, you would look for a header in order to disable the layout. I thought maybe if you loaded a JS module and it imported a view, that view could share the same endpoint as the one used to render the whole page. It's not a big deal though, I was just curious. Thanks for your help. PS. from X import Y syntax would have been useful in cases where IDEs provide auto-completion. I know it's too late for changes now. On 2015/05/30 21:10, Tab Atkins Jr. wrote: On Sat, May 30, 2015 at 6:57 AM, Glen glen...@gmail.com wrote: I apologize if these are silly questions, but: 1. Do ES6 module loaders make use of the browser cache? f.e. If you request a JS module and that JS file is in memory/on disk, will it return that file instead? *All* network requests use the browser cache. Assuming you've set the correct caching headers, you'll get a cached version when you make a request a second time. Only the user can work around this, by clearing their cache or doing a hard refresh. 2. Will ES6 module loaders set a header that indicates that the request is not a regular browser request? (similar to how JS libs set an X-Requested-With header) If not, will it be possible to add custom headers to such requests? What's the reason for this? If you implement a custom loader, you can add whatever headers you want (subject to Fetch restrictions). I don't really know which method browsers will use to load modules – I assume XMLHttpRequest is used for current polyfills, but I don't know what the actual implementations will use (?). Native loader will use the browser's normal request mechanisms. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Maybe we need a reflect API to iterate over instance members
Since class’s members are non-enumerable by default (which is a good choice) we
cannot use for .. in to iterate over all members of an instance, the same
problem could exists in a plain object when we use Object.defineProperty API.
In real world there are some scenarios where we need to iterate over members, A
common example is we need to find all set{SomeThing} methods so we can do an
auto dependency injection.
Certainly we can write a 3rd-party function to find all members through
prototype chain:
function getAllMembersKeys(obj) {
let keys = [];
while (obj) {
keys.push(...Object.getOwnPropertyNames(obj));
obj = Object.getPrototypeOf(obj);
}
return keys;
}
But it doesn’t look nice and lacks considerations of many things such as
Symbol’d keys.
Look around other languages with reflection API, most of them would provide a
method to iterate over all members / properties / methods of an instance, so
why not we provide a set of utility API:
Reflect.getAllMembersNames
Reflect.getAllMemberDescriptors
Reflect.getAllMethodNames
Reflect.getAllMethodDescriptors
Reflect.getAllPropertyNames
Reflect.getAllPropertyDescriptors
Best regards
Gray Zhang
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
