Bergi a.d.bergi at
Thu May 26 21:16:36 UTC 2016

Hi Even!

> Wierd. Was having this discussion / pep-talk with Brendan Eich and think he
> understood that fairly.(

Thanks for that link, but while Brendan Eich seemed to agree with the 
idea that *something* had to be done about defaulting declarations, he 
also showed some confusion about your ideas.
Btw, that gist you linked 
seems to be broken now.

> About lack of answer in the reason, you should read the Medium article
> again, and reconsider what I said about ambiguously written code. I think
> it provides a clear intent, of which we want to avoid re-writing an
> assignment in order to use the logical OR.

Yes, I did reread the article. I know that there are many wrongs about

| var value = value || "another value";

but I failed to understand which ones you mean. By "avoid re-writing an 
assignment" you refer to the duplication/repetition of the variable name?
And what is ambiguous about this code? It's purpose is well-known, it's 
behaviour is well-defined, and after all it's a common JS idiom.

In the medium post you seemed to propose a new "declare" keyword that 
could replace the repeated variable name, and that keyword would 
magically resolve the the contextual variable if I understand correctly. 
OK, regardless of what I think about this idea (too verbose, too 
implicit), what does this have to do with your `Reflect.create` proposal?

> I advice you to read this on MDN
> <>
> which
> explains what I mean about "not an object" . ( It's a built-in object)

Uh, `Reflect` is still an object if that's what you refer to here.
Maybe what you actually wanted is to introduce a new Specification Type 
that works similar to a Reference?

> Where you need to assign it through a object assignment. And yea, the name
> was intentional. What makes this somewhat similar to `Object.create` is
> that we create an logical instance, but not an actual object like
> `Object.create` does.

Sorry, you lost me here again.


More information about the es-discuss mailing list