even stensberg evenstensberg at
Thu May 26 21:57:29 UTC 2016

Yeah, the conversation was about vanilla js, and this links to that. We
want  `Reflect.create` to be a solution instead of writing  `var
DefaultValue = DefaultValue || SomeOtherValue`. That is what the medium
article was about. And that was what the medium article was about, of which
Brendan was agreeing too. The rest of the discussion was about shaping the
code into a proposal, of which we didn't manage to do.

In order for you to fully understand the context I have copy+pasted from
MDN so you can stop arguing of how I wrote "it is not an object". In terms
of how this is not an object, is that is doesn't give us a constructor or
prototype(?) and it behaves statically in that matter.

Unlike most global objects, Reflect is not a constructor. You can not use
it with a new operator
invoke the Reflect object as a function. All properties and methods of
Reflect are static (just like the Math

I guess that this is repetition, but there's no wrong in saying this again.
IMO. was bad typed by me there. By logical instance I mean that it
should  remove
code with logical operators, which uses the existing variable, to reassign
it with an logical operator as a fallback value.

About the Reflect instance, that is wrong, should be revised, indeed. I
used it as outside JavaScript context. And no, Reflect doesn't become a
constructor, both of us know that, so I don't know why you brought it up.
Fail in this context means that the object returned with an error, null or
undefined. I disagree. People understand the relationship between error,
null and undefined as similar, meaning if things go south, this is where we
put our try/catch as an function object.

The examples are to show the use of undefined without the "proposal". ( It
chronological, so last example would be natural in this use case ) .

To Bergi:

Yeah, it serves its purpose, but I think that   `var value = value ||
"another value";` is bad as opposed to how I'd tackle it with Reflect. I
always think that you don't need to write things as-they-are in forums
where people have worked with JS quite some time. I tried to explain why I
mean that this isn't a real object by saying that it doesn't contain
prototype or constructor and thereby people got the analogy. Often when I
say things are not things, as by object is not objects, I assume people
manage to reason without having to pin facts straight into their faces.
Often I and people find that disrespectful( people try to teach you like a
kid). Anyways, Reflect cannot be created as Object.Reflect, and that is
what I mean by you having to assign it like:  `var Value = Reflect.create()

I'd like us to make a thread/ issue on the repo, so we avoid spamming
people if that is fine? Also, if you have any other questions regarding how
things are written, please, do file a PR, I bet you are better at
explaining things in text than I am. :)

On Thu, May 26, 2016 at 11:16 PM, Bergi <a.d.bergi at> wrote:

> 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.
>  Bergi
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list