-
-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ES6 Proxy to throw on non-existing assertions #407
Comments
Firefox 36 has Proxies with function Assertion(obj, msg, stack) {
flag(this, 'ssfi', stack || arguments.callee);
flag(this, 'object', obj);
flag(this, 'message', msg);
return new Proxy(this, {
get: function(target, name) {
if (name in target) {
return target[name];
}
throw new Error('Cannot find property ' + name);
}
});
} Of course, this is all well and good but until even a handful of engines support this - it's basically pointless to implement. Also we'd need to have a good test suite to back this up. I'll mark this as |
IMO even doing it in 1-2 popular browsers is enough. People usually mostly test a lot manually on Firefox/Chrome during development and then run tests on everything supported via CI (Travis, Jenkins). So even having it just in Firefox & Chrome will make people see misspelled assertion names quickly and those tests won't get to other browsers in the broken state. This won't cover assertions that are run only in specific browsers but that's the minority. |
Yeah, I agree. "handful of engines" was a figure of speech. We could probably implement this when Firefox/Chrome both get proxies. |
That seems like a sensible strategy. :) Should we keep this bug open until Michał Gołębiowski |
Yup 😄 |
This will be nice! PS: Chrome/V8 supports it reportedly with the |
A brief read of those issues seems to indicate existing support in Chrome for Proxies is buggy. That makes me nervous about supporting Proxies and getting an influx of difficult to track/fix bug reports. So I'd say we still hold off here. |
Yes, current v8 Proxy implementation is broken, don't rely on that.
Michał Gołębiowski |
Thanks for the info! |
Edge has now even better Proxy support than Firefox, 21/21 points in the Kangax table. Edge officially comes out with Windows 10 in a month. So we have 2 browsers now, Firefox & Edge, maybe that's enough? Chrome by default doesn't have the |
Thanks for the info @mzgol. As mentioned, mostly concerned about users enabling the flag in chrome/node and having a broken implementation, to which we get issues because of the broken implementation. I think we'll pull the trigger as soon as Chrome/node either gets a working impl, or disables the broken one. |
It's already disabled unless you specifically use the command line flag to
enable the broken implementation.
But OK, Chrome will most likely implement it within a few months anyway.
|
To be precise:
Users of Node.js/io.js versions that don't support proxies (currently all but that will change) will still get a broken implementation if they use the So I don't really understand this remark:
This will not change for existing versions. And I expect that even in a year there will be a lot of Node.js 0.12/older io.js users. |
We could look at feature detecting for broken Proxies. According to the spec (and firefox), > new Proxy({}, {})
TypeError: object is not a function
at repl:1:5
at REPLServer.defaultEval (repl.js:132:27)
at bound (domain.js:254:14)
at REPLServer.runBound [as eval] (domain.js:267:12)
at REPLServer.<anonymous> (repl.js:279:12)
at REPLServer.emit (events.js:107:17)
at REPLServer.Interface._onLine (readline.js:214:10)
at REPLServer.Interface._line (readline.js:553:8)
at REPLServer.Interface._ttyWrite (readline.js:830:14)
at ReadStream.onkeypress (readline.js:109:10)
> And in io.js I get: > new Proxy({}, {})
TypeError: Proxy is not a function
at repl:1:5
at REPLServer.defaultEval (repl.js:155:27)
at bound (domain.js:254:14)
at REPLServer.runBound [as eval] (domain.js:267:12)
at REPLServer.<anonymous> (repl.js:309:12)
at emitOne (events.js:77:13)
at REPLServer.emit (events.js:169:7)
at REPLServer.Interface._onLine (readline.js:208:10)
at REPLServer.Interface._line (readline.js:547:8)
at REPLServer.Interface._ttyWrite (readline.js:824:14)
> (As mentioned, Firefox passes this - as should a spec compliant implementation). So in one foul swoop of feature detection, we could do: var supportsProxies = false;
try {
new Proxy({}, {});
supportsProxies = true;
} catch(e) {
} |
I'd say I think we're about ready to try supporting this. PR's welcome @mzgol @jakubholynet |
The obvious solution would be to introduce a breaking change and require all assertions to be actual function calls: expect({}).to.be.true() Should.js had the same issue and they decided to get rid of assertions on property access in should.js 7 (changelog). |
Update: latest Chrome (v49) now ships with Proxy support. This means Node.js 6, to be released in April, will support Proxy as well. |
This is the obvious and right solution imo. It'd be a breaking change, sure, but it'd be worth it. |
Added in #721 |
With ES6 proxies it should be possible to have the following:
throw which would remove one of the reasons why assertions on property access are problematic.
This will still need to work in browsers not supporting ES6 proxies (now: all browsers but this will soon change).
Refs #56.
The text was updated successfully, but these errors were encountered: