Object literal as syntactic sugar
Herby Vojčík wrote:
Hello,
to make things more DRY in spec and more consistent, what if {some_content} in expression context would be defined as syntactic sugar for (new Object).{some_content}?
No! You have just reintroduced the ES3 bug where a rebound or shadowed Object can be used to steal data expressed via an object literal (formerly, pre-built-in-JSON.parse, via eval).
An object literal {...} is not equivalent to (new Object).{...}. The original value of Object.prototype is used. It turns out no observable constructor effects come from the original value of Object, so there's no need to construct a plain empty object, just allocate one that delegates directly to Object.prototype.
I think you are making a mistake treating the spec as code to "desugar" from more primitive (object literal) to more derived (mustache expression) forms. Indeed it seems to me the pun on object literals that mustache does is not helpful, on balance. There is no new object, not even an observable throwaway.
Brendan Eich wrote:
Herby Vojčík wrote:
Hello,
to make things more DRY in spec and more consistent, what if {some_content} in expression context would be defined as syntactic sugar for (new Object).{some_content}?
No! You have just reintroduced the ES3 bug where a rebound or shadowed Object can be used to steal data expressed via an object literal (formerly, pre-built-in-JSON.parse, via eval).
An object literal {...} is not equivalent to (new Object).{...}. The original value of Object.prototype is used. It turns out no observable constructor effects come from the original value of Object, so there's no need to construct a plain empty object, just allocate one that delegates directly to Object.prototype.
I think you are making a mistake treating the spec as code to "desugar" from more primitive (object literal) to more derived (mustache expression) forms. Indeed it seems to me the pun on object literals that mustache does is not helpful, on balance. There is no new object, not even an observable throwaway.
/be
I meant it so, with the always used "use original value of ...", of course, just did not write it. Of course, I did not mean to use (new Object) in dynamic manner.
This was only about defining that what is inside {} is that same what is inside .{} and the same object would be created if .{} was applied to safe empty object.
Hello,
to make things more DRY in spec and more consistent, what if {some_content} in expression context would be defined as syntactic sugar for (new Object).{some_content}?
Hello, to make things more DRY in spec and more consistent, what if {some_content} in expression context would be defined as syntactic sugar for (new Object).{some_content}? Herby