es-discuss Digest, Vol 111, Issue 83

Isiah Meadows isiahmeadows at gmail.com
Fri May 27 14:28:05 UTC 2016


Try sending it with `unsubscribe` as the subject and no text. Or you could
always go to the link and do it from there. ;-)

On Thu, May 26, 2016, 16:28 Will <willdchoy at gmail.com> wrote:

> unsubscribe
>
> On Thu, May 26, 2016 at 4:21 PM, <es-discuss-request at mozilla.org> wrote:
>
>> Send es-discuss mailing list submissions to
>>         es-discuss at mozilla.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mail.mozilla.org/listinfo/es-discuss
>> or, via email, send a message with subject or body 'help' to
>>         es-discuss-request at mozilla.org
>>
>> You can reach the person managing the list at
>>         es-discuss-owner at mozilla.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of es-discuss digest..."
>>
>> Today's Topics:
>>
>>    1. Re: Observing whether a function is strict (Claude Pache)
>>    2. Reflect.create() (even stensberg)
>>    3. Suggestion: "Object.hasOwnProperty" (doodad-js Admin)
>>    4. Re: Reflect.create() (Bergi)
>>
>>
>> ---------- Forwarded message ----------
>> From: Claude Pache <claude.pache at gmail.com>
>> To: Mark Miller <erights at gmail.com>
>> Cc: "Mark S. Miller" <erights at google.com>, es-discuss <
>> es-discuss at mozilla.org>
>> Date: Thu, 26 May 2016 17:55:13 +0200
>> Subject: Re: Observing whether a function is strict
>>
>> Le 26 mai 2016 à 17:02, Mark Miller <erights at gmail.com> 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 of
>> `Function#arguments` just presented itself to my mind, and I really didn’t
>> thought whether that has any consequence.
>>
>> —Claude
>>
>>
>>
>> On Thu, May 26, 2016 at 4:03 PM, Claude Pache <claude.pache at gmail.com>
>> wrote:
>>
>>>
>>> Le 26 mai 2016 à 13:23, Mark S. Miller <erights at google.com> a écrit :
>>>
>>>
>>>
>>> On Thu, May 26, 2016 at 11:25 AM, Claude Pache <claude.pache at gmail.com>
>>> wrote:
>>>
>>>>
>>>> > Le 26 mai 2016 à 10:43, G. Kay Lee <
>>>> balancetraveller+es-discuss at 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 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 the "strict mode" as the one and only standard
>>>> behavior. If so, then introducing any additional language feature to help
>>>> detecting strict/non-strict is certainly not ideal.
>>>>
>>>> AFAIK, there is no plan to remove non-strict mode.
>>>>
>>>> And to be clear about my intentions, what I have in the back of my head
>>>> was certainly not "introducing any additional language feature to help
>>>> detecting strict/non-strict" (yuck!), but whether it makes sense to think
>>>> about a possible way to remove that leak from `Function#arguments` and
>>>> `Function#caller`. But it would be premature to consider that issue without
>>>> *at least* an answer to my original question: Are there other ways...?
>>>>
>>>
>>> Hi Claude, what do you mean by "remove that leak"? Hypothetically, let's
>>> say you had such a test and that it was reliable. How would you use it
>>> remove the leak? (This is probably also the best way to clarify what
>>> precisely you mean by removing the leak.)
>>>
>>>
>>> Maybe that "leak", namely observing whether a function is strict, is not
>>> something to care about.
>>>
>>> But here is what I think to be a possible way to remove it: Because
>>> `Function#arguments` and `Function#caller` do return `null` for sloppy
>>> functions in some circumstances (namely, when the function is not found in
>>> the call stack), let them always return `null` for non-sloppy functions.
>>>
>>> —Claude
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>>   Cheers,
>>   --MarkM
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: even stensberg <evenstensberg at gmail.com>
>> To: es-discuss <es-discuss at mozilla.org>
>> Cc:
>> Date: Thu, 26 May 2016 19:42:10 +0200
>> Subject: 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 any changes or opinions of this via Github, not here. This is
>> because ES-Discuss is a bit messy when it comes to feedback, I.E that I get
>> a mail every 30th minute of a one line comment. If it's absolutely
>> necessary, drop a comment here, but I strongly advice you to try out GitHub
>> issues.
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: doodad-js Admin <doodadjs at gmail.com>
>> To: <es-discuss at mozilla.org>
>> Cc:
>> Date: Thu, 26 May 2016 15:26:52 -0400
>> Subject: 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 or
>> their own code.
>>
>>
>>
>> Claude Petit
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Bergi <a.d.bergi at web.de>
>> To: es-discuss at mozilla.org
>> Cc:
>> Date: Thu, 26 May 2016 22:21:56 +0200
>> Subject: 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 post](
>> https://medium.com/@ev1stensberg/iteration-in-javascript-needs-a-tectonic-shift-a74b6554bbd7)
>> but failed to understand anything (and didn't get any point you were going
>> to make). As such, the "Reason" for this proposal is completely missing to
>> me.
>>
>> While I fail to understand what your proposal is all about, it seems to
>> have something to do with defaulting values. And great, you've even asked
>> the question "How is this different to Default Param in ES6 / the OR
>> operator?" yourself in that text - but there is no answer?!
>>
>> The next thing that completely escaped me is your API description
>>
>> | `Reflect.create(target, value, [DefaultValue])`
>> |
>> | Creates a Reflect, which is not an object.
>>
>> Uh, what? What is "a Reflect"?
>>
>>
>> And the first thing that came to my mind after I read what you're talking
>> about is that you should rename the proposal. `Reflect.create` will remind
>> everyone of `Object.create` (given that some of the methods are duplicated
>> between `Object` and `Reflect`) and one would expect that they do the same
>> or at least have a similar purpose.
>> You seem to be proposing something completly different that has nothing
>> to do with creation.
>>
>> Kind regards,
>>  Bergi
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160527/931d84af/attachment-0001.html>


More information about the es-discuss mailing list