On Thu, Nov 13, 2014 at 1:57 AM, Jeff Morrison lbljef...@gmail.com wrote:
Note that in my crazy idea I didn't say rethrow -- I carefully called it
out as more of a log than a throw.
I thought the plan was to have something equivalent to window.onerror
for promises.
--
well, Proxy can be a diabolic beast
```js
Object.setPrototypeOf(
Object.prototype,
new Proxy(Object.prototype, evilPlan)
)
```
having no way to understand if an object is a Proxy looks like a footgun to
me in the long term, for libraries, and code alchemists
You indeed wrote that different
On 13 November 2014 12:25, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
well, Proxy can be a diabolic beast
```js
Object.setPrototypeOf(
Object.prototype,
new Proxy(Object.prototype, evilPlan)
)
```
having no way to understand if an object is a Proxy looks like a footgun to
Same would be reassigning any prototype but it was just to make the
diabolic point... also yeah, sPO is powerful, that's why we love it!
( it's also way less diabolic than any __proto__ string floating around
;) )
On Thu, Nov 13, 2014 at 11:44 AM, Andreas Rossberg rossb...@google.com
wrote:
On
What happens if a module isn't able to be found? Is that implementation
defined, or have I missed it in the spec?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It should throw a static error, the loader is where this is specified I
believe, but it looks like the loader was pulled out into it's own spec
https://github.com/rwaldron/tc39-notes/blob/b1af70ec299e996a9f1e2e34746269fbbb835d7e/es6/2014-09/sept-25.md#loader-pipeline,
not sure where that ended up
The best defense is Object.freeze(Object.prototype);
No application worth considering needs to arbitrarily modify
Object.prototype at an arbitrary point in time (or someone should bring
a use case for discussion). It usually shouldn't and even if it does, it
should do it at startup and freeze
On 11/13/14, 6:44 AM, Andreas Rossberg wrote:
Well, the actual diabolic beast and universal foot gun in this example
is setPrototypeOf. ;)
Note that there is at least some discussion within Mozilla about trying
to make the prototype of Object.prototype immutable (such that
On 11/13/14, 4:25 AM, Anne van Kesteren wrote:
On Thu, Nov 13, 2014 at 1:57 AM, Jeff Morrison lbljef...@gmail.com wrote:
Note that in my crazy idea I didn't say rethrow -- I carefully called it out as more of
a log than a throw.
I thought the plan was to have something equivalent to
On Nov 13, 2014, at 5:16 AM, Calvin Metcalf wrote:
It should throw a static error, the loader is where this is specified I
believe, but it looks like the loader was pulled out into it's own spec
On Thu, Nov 13, 2014 at 7:13 PM, Jeff Morrison lbljef...@gmail.com wrote:
I think that's what this discussion is about. Such a log could be
dispatched to window.onerror as well as console (etc).
Coming back to this after sleeping on it, though: The biggest problem I can
think of with my
On Nov 12, 2014, at 12:12 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-11-12 19:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com:
I agree and I want to know if you think this is worth revisiting once more?
Next meeting's agenda?
I don't think we've ever discussed this issue before
On Nov 12, 2014, at 11:58 AM, Jeremy Martin wrote:
My opinion is that array testing is fundamental to core JS and is worth the
exception.
Knowing that Array.isArray() tests fail for proxies, I'd be afraid to ever
create a Proxy for an array that I don't control the complete lifecycle of.
2014-11-13 20:31 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com:
3) Proxies. Should Array.isArray treat proxy instances specially? To
answer this question we need to think about what a ES programmer actually
thinks Array.isArray means? The meaning that ES5 established is that
On Nov 13, 2014, at 3:21 PM, Cyrus Najmabadi wrote:
Hey Allen,
We have a followup question. This time it’s more about understanding the
rationale behind things, rather than asking what the spec is explicitly
stating.
Specifically, I’m curious why the spec says this in “14.2.1
That seems reasonable* Allen.
And I appreciate confirmation that our reading of the spec is in line with
yours.
-- Cyrus
* I personally prefer the approach that moving to new language constructs may
come with additional restrictions that are more onerous. But that's just me.
For
Allen Wirfs-Brock wrote:
We might redefine Array.isArray to be based upon testing for
@@isConcatSpreadable but that potentially would give different results
for legacy uses that did __proto__ hacking such as I mentioned in my
previous mote.
How about we turn the @@ property into
Specifically, while the spec says that :
SomeProd[Yield,GeneratorParameter]
Is equivalent to:
1) SomeProd
2) SomeProd_Yield
3) SomeProd_GeneratorParameter
4) SomeProd_Yield_GeneratorParameter
It's doesn't seem like it is actually possible for any path of
18 matches
Mail list logo
