oh ... that one, it was for Boris who wrote:

> This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike "window", "self", or "global").... ;)

I meant that your `eval` wasn't more reliable than window, self, or global,
because ot could have been redefined as well ... but this is not about
shadowability, it's about having one name that fits in every JS situation:
server, worker, document

`global` instead of `window` and/or `self` is a clear win for everyone,
being curse forever to check it `typeof window` or `typeof global` is not
undefined is ... well, the most basic and striking fragmentation case we
have at the root of the language ^_^



On Fri, Apr 17, 2015 at 5:13 PM, Mark S. Miller <erig...@google.com> wrote:

>
>
> On Fri, Apr 17, 2015 at 9:05 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I've never said unshadowable ...
>>
>
> You did:
>
> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> also `eval` can be in-scope redefined as much as global, window, or self,
>> so no, that's actually not a solution.
>>
>
>
>
>
>
>
>> I am saying that `global` should be a global reference to the global
>> object which is mentioned in ES6/2015 but it's not specified how it should
>> be referenced. `window` is not welcome even in DOM tools like browserify,
>> `global` is ubiquitous in its meaning, it does not confuse anyone like a
>> `self` in node.js or others would do, and it will solve forever the hassle
>> of referencing *by deafault* a global object without needing to eval,
>> Function('return this'), [].sort(), or whatever wizardy you coudl came up
>> to retrieve and/or reference the global object.
>>
>> It's deadly simple: whatever freedom implementors have to put window
>> and/or self in, they MUST put a `global` reference too ... that will make
>> everything else redundant, in the long term, and not vice-versa
>>
>> Is this really that complicated to ship?
>>
>> On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller <erig...@google.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> also `eval` can be in-scope redefined as much as global, window, or
>>>> self, so no, that's actually not a solution.
>>>>
>>>> Btw, I wasn't asking for a workaround, I was proposing to officially
>>>> bring ES 2015 `global` object as language reference in ES7/201X
>>>>
>>>
>>> In an unshadowable manner? Never gonna happen. Everything that provides
>>> authority must be virtualizable.
>>>
>>>
>>>
>>>>
>>>> It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
>>>> millions of results in Github for `typeof global` apparently got unnoticed 
>>>> )
>>>>
>>>> On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
>>>> andrea.giammar...@gmail.com> wrote:
>>>>
>>>>> it's a no-go under CSP so it's as bad as `Function('return this')()`
>>>>>
>>>>> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky <bzbar...@mit.edu>
>>>>> wrote:
>>>>>
>>>>>> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>>>>>>
>>>>>>> (1,eval)('"use strict"; this')
>>>>>>>
>>>>>>
>>>>>> This has the drawback of making eyes bleed, but the benefit of
>>>>>> working reliably (unlike "window", "self", or "global").... ;)
>>>>>>
>>>>>> -Boris
>>>>>>
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>>     Cheers,
>>>     --MarkM
>>>
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to