No modes, please. "use strict" was a terrible idea, and I don't want to see that repeating. If you're worrying about typeof, better solution would be to deprecate it; and it's a job for linters, not compilers. 29.07.2014, 23:02, "Christoph Martens" cmarten...@gmail.com:Hey all, I just read a
I don't have an answer, but the metadata property of the loadRecord object
was designed to be the place where you put your own custom metadata so that
it's persisted across hooks. And it works in es6-module-loader:
http://jsbin.com/kutey/2/edit?js,output.
Juan
Ok thanks, I see that this was added and I did not notice. (I think this
kind of creeping overspecification annoying but inevitable I suppose).
jjb
On Wed, Jul 30, 2014 at 7:20 AM, Juan Ignacio Dopazo jdop...@yahoo-inc.com
wrote:
I don't have an answer, but the metadata property of the
The spec seems inconsistent about the metadata property. The define()
function of Loader accepts options.metadata:
---
26.3.3.2Reflect.Loader.prototype.define ( name, source [ , options ] )
...
8. Let metadata be GetOption(options, metadata).
9. ReturnIfAbrupt(metadata).
10. If metadata is
I wonder if this is related to normalize not having access to the metadata
http://jsbin.com/pazovohi/1/
On Wed, Jul 30, 2014 at 12:21 PM, John Barton johnjbar...@google.com
wrote:
The spec seems inconsistent about the metadata property. The define()
function of Loader accepts
On Wed, Jul 30, 2014 at 4:31 AM, Katelyn Gadd k...@luminance.org wrote:
History has shown that native code developers concerned with
performance (game devs, graphics devs, etc) will happily use
approximations of these special functions when performance is
important, and will pick
Andreas Rossberg wrote:
I think this subtle discrepancy is both unfortunate and unnecessary
[1]. Moreover, with ES7 do expressions, I would like it to hold that
(...) = {...}≡(...) = do {...}
I channeled you as best I could, and Dmitry Lomov kindly channeled you
on this point,
Hi Boris,
It seems you're right (reproduced on Chrome and Safari). These examples
clearly violate all the invariants related to non-configurable properties.
If I understand correctly, the form DOM element's named input properties
'shadow' the actual JS properties defined on the DOM object. Even
8 matches
Mail list logo
