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
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';
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,
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
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
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
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
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
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
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);
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
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
12 matches
Mail list logo
