as side note: in node.js using --harmony flag ... what a developer should do there to understand that a partially non standard version of Proxy is there instead of the real one?
Let's imagine I am a client/server library author ... just for a second, I'd like to grant one behaviour across platforms ... I'd love V8 to flag experimental features as v8Proxy instead, at least I know what I am dealing with!!! Don't care about multiple checks, as long as I can grant consistency. This is a concern of mine that keeps coming up ... off topic here On Thu, Dec 19, 2013 at 10:47 PM, Andrea Giammarchi < [email protected]> wrote: > thanks for the exhaustive answer, useful and more than appreciated. > > The example was addressing one problem, the need for an extra variable, > and was not meant to represent the best way to detect if the Proxy was the > meant one. > > About this, since you pointed that out, I'll come back on vendor prefixes, > and the fact that to know if Proxy is the old one, and MDN has even a > specific page for it, or "the real/standard one", a developer should go > down the [native] check on the constructor and the inevitable try/catch > since both old and new Proxy functions have that create method as public > static. > > Proxy is a very good example of those hard to detect features since the > vendor/engine decided that prefixes were not a good option ... well, > if(typeof Proxy === 'undefined') brings you nowhere in current node.js, as > example, neither in any Chrome with experiments enabled ... and about that, > there is no exposed flag anyone can feature detect to understand if the > current constructor is out of an experimental feature or it's the real one > spec'd and supported. > > Best Regards > > > > > > > On Thu, Dec 19, 2013 at 7:05 PM, Brendan Eich <[email protected]> wrote: > >> Andrea Giammarchi wrote: >> >>> why is this not possible, giving the ability to understand through >>> typeof if there is a value or not? >>> >>> ```javascript >>> // defined as const >>> // reserved in this scope >>> // but not assigned yet >>> const WHATEVER; >>> if (condition) { >>> // first come, first serves >>> WHATEVER = 123; >>> // that's it! const defined for the whole scope >>> // immutable from now on >>> } else { >>> WHATEVER = 456; >>> } >>> >> >> Past JS2/ES4 designs have allowed this, but it requires definite >> assignment analysis and use-before-defining-assignment error checking. >> >> In general, such checks can't be static in JS, so the language and VM >> complexity blow up a bit with runtime checking for an "uninitialized" (not >> same as undefined) sentinel value that must be guarded against by a read >> barrier where it can't be proven unnecessary. >> >> This is pretty obnoxious for implementors, not great for users either >> (did I declare const IMPORTANT; and forget to assign IMPORTANT= in some >> branch of control flow that my tests miss?). >> >> It's not in Harmony. We require an initialiser as part of the const >> declaration syntax. What you are doing here, by many measures, is varying a >> variable from its default (undefined) value to a new value. >> >> If you want that variable to stop varying after, and you need it as a >> global (window) object property anyway, use Object.defineProperty to make >> it non-writable. >> >> BTW, the last version your head post gave, >> >> const ES6_PROXY = function(){ >> >> try { >> new Proxy({},{}); >> return true; >> } catch(o_O) { >> return false; >> } >> }(); >> >> isn't bad at all, but are you really concerned about false-positive >> (typeof Proxy != "undefined") test results? Some other Proxy could easily >> be a function that does not throw when called with two objects as >> arguments. The standard object detection pattern: >> >> if (typeof Proxy == "undefined") >> this.Proxy = (/* polyfill Proxy here somehow... */); >> >> often has a leading >> >> var Proxy; >> if (typeof Proxy == "undefined") >> this.Proxy = (/* polyfill Proxy here somehow... */); >> >> precisely to avoid errors from static analyzers looking for bare Proxy >> uses without a declared var in scope. >> >> In any event, these patterns want *variables*, not constants, because >> they must work when there's already a binding. And you cannot redeclare >> with const (or let or class), as Rick points out. >> >> /be >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
