Re: Reflect.create()

I've refactored the project, more yet to come, but have a look: https://github.com/ev1stensberg/proposal-reflect-or. Still need to put up an example and implementation details ( currently on the to-do list) On Fri, May 27, 2016 at 3:33 AM, G. Kay Lee < balancetraveller+es-disc...@gmail.com>

Re: Reflect.create()

Hi Even, I think everyone who has replied above has all been offering some very constructive feedbacks for you to chew on. The key takeway, if you haven't noticed already, is that your understanding of the language is flawed, and people simply cannot help you or continue their discussions with

Re: Reflect.create()

Is there anything bad about getting feedback before reiteration? This was meant for having some feedback and improvements. If you got some input, you are free to join by submitting a issue on GitHub! Just to clear things up, ES Discuss is about discussing the language, not only submitting

Re: Reflect.create()

Is there anything bad about getting feedback before reiteration? This was meant for having some feedback and improvements. If you got some input, you are free to join by submitting a issue on GitHub! On Fri, May 27, 2016 at 2:59 AM, Renki Ivanko wrote: > Everything

Re: Reflect.create()

Everything about this is confusing; you should slow down and think things through more. R. On Fri, May 27, 2016 at 1:25 AM, even stensberg wrote: > That's one of the reasons why GitHub is a better place to discuss this ;) > > As I tried to say, this is work in

Re: Reflect.create()

That's one of the reasons why GitHub is a better place to discuss this ;) As I tried to say, this is work in progress, meaning I'd like input on this as well as improvements on the actual proposal. As by last line, what is it that you don't understand? Hit me up at GitHub and I'll try to clear

Re: Reflect.create()

… was bad typed by me there. Indeed it was. 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

Re: Reflect.create()

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

RE: Suggestion: "Object.hasOwnProperty"

>> This would break a Web, a I have seen code that relies on >> Object.hasOwnProperty === Object.prototype.hasOwnProperty Sorry, I didn’t remember that the constructor inherits it. >> Anyway, it would be handy to have such function as `Reflect.hasOwn` or >> something like that. Yeah, maybe

RE: Suggestion: "Object.hasOwnProperty"

This would break a Web, a I have seen code that relies on Object.hasOwnProperty === Object.prototype.hasOwnProperty Anyway, it would be handy to have such function as `Reflect.hasOwn` or something like that. On 26 May 2016 10:38 p.m., "doodad-js Admin" wrote: > >> Both the

Re: Reflect.create()

Hi Even! Wierd. Was having this discussion / pep-talk with Brendan Eich and think he understood that fairly.( https://twitter.com/ev1stensberg/status/722180638971936768) Thanks for that link, but while Brendan Eich seemed to agree with the idea that *something* had to be done about

RE: Reflect.create()

I agree with Bergi. > Brendan Eich and think he understood that fairly I can't see that. He says things like "what's to propose?", "what is declare? I don't think core language needs to grow", "What does this have to do with promises?", "I don't see the point" and "It's not making sense,

Re: Reflect.create()

Hi Bergi! If you read the description, it clearly says unofficial proposal, of which draft means a mock-up for improvement. I thought that was retorical enough for people to understand, I'll change that up. Wierd. Was having this discussion / pep-talk with Brendan Eich and think he understood

RE: Suggestion: "Object.hasOwnProperty"

>> Both the concern of `someObj.hasOwnProperty(somePropertyName)` attempting to >> call the `hasOwnProperty` property of `someObj` rather than walking the >> prototype chain to get `Object.prototype.hasOwnProperty`, and the >> concern >> of `someObj` having a null prototype (or otherwise not

Re: Suggestion: "Object.hasOwnProperty"

`Object.hasOwnProperty` already exists via the prototype chain, but I'm guessing you wish it did something different. Both the concern of `someObj.hasOwnProperty(somePropertyName)` attempting to call the `hasOwnProperty` property of `someObj` rather than walking the prototype chain to get

Re: es-discuss Digest, Vol 111, Issue 83

unsubscribe On Thu, May 26, 2016 at 4:21 PM, wrote: > Send es-discuss mailing list submissions to > es-discuss@mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via

Re: Reflect.create()

even stensberg wrote: I wrote up a draft about how I'd like this to look at: https://github.com/ev1stensberg/proposal-reflect-or I'm sorry for the harsh tone, but that's not a draft. I tried to read [your medium

Suggestion: "Object.hasOwnProperty"

Hi, I think to create "Object.hasOwnProperty". Often, an object is used to store key/value pairs and most users forget that "hasOwnProperty" can be also be a key. Objects created by "Object.create(null)" don't inherit this function and users get lost when they get such an object from a library

Reflect.create()

Before going further, please note that feedback will be on Github, since we want to avoid spamming in ES Discuss in order to provide a much cleaner system. I wrote up a draft about how I'd like this to look at: https://github.com/ev1stensberg/proposal-reflect-or, please note that I humbly accept

Re: Observing whether a function is strict

> Le 26 mai 2016 à 17:02, Mark Miller a écrit : > > I don't get it. What is being removed? A way to observe (almost surely?) that a given ECMAScript function is strict. > What purpose does this accomplish? As I've said, maybe nothing to care about. That strange capability

Re: Observing whether a function is strict

I don't get it. What is being removed? What purpose does this accomplish? On Thu, May 26, 2016 at 4:03 PM, Claude Pache wrote: > > Le 26 mai 2016 à 13:23, Mark S. Miller a écrit : > > > > On Thu, May 26, 2016 at 11:25 AM, Claude Pache

Re: Observing whether a function is strict

> Le 26 mai 2016 à 13:23, Mark S. Miller a écrit : > > > > On Thu, May 26, 2016 at 11:25 AM, Claude Pache > wrote: > > > Le 26 mai 2016 à 10:43, G. Kay Lee >

A plan to help TC39 become more open up to community contributions and participations

(This is a continuation of [a previous discussion]( https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues )) So, to summarize, while rules and platforms currently in place do allow for community contributions, they are hardly friendly ones. A few issues: * The mailing

Re: Observing whether a function is strict

On Thu, May 26, 2016 at 1:23 PM, Mark S. Miller wrote: > > > On Thu, May 26, 2016 at 11:25 AM, Claude Pache > wrote: > >> >> > Le 26 mai 2016 à 10:43, G. Kay Lee < >> balancetraveller+es-disc...@gmail.com> a écrit : >> > >> > I was under the

Re: Observing whether a function is strict

On Thu, May 26, 2016 at 11:25 AM, Claude Pache wrote: > > > Le 26 mai 2016 à 10:43, G. Kay Lee < > balancetraveller+es-disc...@gmail.com> a écrit : > > > > I was under the impression that strict mode is a (temporary) workaround > to get rid of unwanted bad parts of the

Re: How about a "named true" and a "named true property"

This is more a problem to be solved in API design and if you see such a method being introduced to libraries or specifications, you should raise your concerns with the author(s). Fortunately, Ecma-262 seems to avoid this pitfall by accepting objects-as-dictionaries, and most newer web APIs seem

RE: How about a "named true" and a "named true property"

As Isiah Meadows said, you can just use variables. ``` var removeNode = true; control.dispose(removeNode); ``` ``` var silent = true, disableValidation = true, destroyOldValue = false; model.set('foo', newValue, {silent, disableValidation, destroyOldValue});``` From:

Re: Observing whether a function is strict

> Le 26 mai 2016 à 10:43, G. Kay Lee a > écrit : > > I was under the impression that strict mode is a (temporary) workaround to > get rid of unwanted bad parts of the language without instantly breaking > anything. The long term question thus should be:

Re: How about a "named true" and a "named true property"

Here you go... ``` var deep; $.extend(!deep, object1, object2); // true $.extend(!!deep, object1, object2); // false ``` What you're asking is essentially another `!`. On Thu, May 26, 2016 at 5:02 PM, Gray Zhang wrote: > I don't really know how to name this feature, but

Re: How about a "named true" and a "named true property"

Is defining a variable set to true not sufficient? On Thu, May 26, 2016, 05:02 Gray Zhang wrote: > I don't really know how to name this feature, but I find it quite > neccessary > > In JavaScript land there are many functions with parameters of type > boolean, and

Re: Observing whether a function is strict

I would be mostly okay if sloppy mode goes away. The only use case I have now for it is for accessing the global in a platform independent manner, but the System.global proposal eliminates this need. I write all code in strict mode now, so I only see likely performance benefits from completely

How about a "named true" and a "named true property"

I don't really know how to name this feature, but I find it quite neccessary In JavaScript land there are many functions with parameters of type boolean, and invocations to these functions do not have high readability, for example jQuery have a `clone` method with a parameter deep of type

Re: Observing whether a function is strict

I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish

Re: Observing whether a function is strict

> Le 26 mai 2016 à 09:57, Mathias Bynens a écrit : > > On Thu, May 26, 2016 at 9:48 AM, Claude Pache wrote: >> I was wondering whether there is a way to observe whether a given random >> function is strict (or sloppy, or neither). >> […] Are there

Re: Observing whether a function is strict

On Thu, May 26, 2016 at 9:48 AM, Claude Pache wrote: > I was wondering whether there is a way to observe whether a given random > function is strict (or sloppy, or neither). > […] Are there other ways? (If not, I find it somewhat unfortunate that only > such nonstandard

Observing whether a function is strict

Hi, I was wondering whether there is a way to observe whether a given random function is strict (or sloppy, or neither). Apart from flawed guess based on `Function#toString` (flawed, because it could only detect "use strict" prologue, which is insufficient), the only way I see is to observe