Has v8 deprecated __proto__ yet? cc @nodejs/v8

The ES spec has "deprecated" __proto__ by putting it in annex B, but it will never be removed from engines. Deprecation is dumb on the web and never works, and the whole concept of ES deprecating them is dumb.

That said, I still think it's reasonable to do this replacement, because it's prettier. I'm surprised this is the only usage of __proto__ in the codebase though.

This may be a silly question, but do these two things do exactly the same thing internally, at least in v8? I'm thinking about if there would be any weird/unexpected changes in performance using one method over the other (as far as object property access goes, not the time spent actually setting the prototype during startup).

Oh I didn't know that ES6 made __proto__ an optional feature for non-browser hosts.

ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter.

Looks like usage of __proto__ is okay for the time being then.

I wonder if we can actually inherit it from EventEmitter instead of changing prototype.

process object is created during the Environment creation right? Will we be able to load EventEmitter by then?

No, but I think we can instantiate it later, or make this object internal to some object inherited from EventEmitter.

Do you mean creation of process object need not happen at the time of Environment creation?

There is no hard requirement for this.

I'm just throwing out random ideas, it doesn't mean that they should be turn into code :) At least not immediately! ;)

Okay :-) I was just trying to understand your ideas better.

@JacksonTian could you add the corresponding rule to our linter (in a separate commit) ?
It would be http://eslint.org/docs/rules/no-proto.html

LGTM

LGTM

CI: https://ci.nodejs.org/job/node-test-pull-request/1561/

@targos I will do it. thanks.

Landed in 9aebb00