a.d.bergi at web.de
Thu May 26 21:16:36 UTC 2016
> 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
> 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