Couldn't all this be solved by allowing = also for object literals and
promoting its use? People get used to the fact that = is the "normal"
way and : is the "special" way plus they are told JSON only has : for
both historical and security reasons.
Because I feel the main problem felt here is "don't help developers do
[[DefineProperty]] all over". I say : should definitelybe there
(consistency, I value it very highly, so no = only), but by saying
"using = is the right style" people can move away from using : in
literal, so they will also not use it in mustache.
Herby
Tab Atkins Jr. wrote:
On Tue, May 29, 2012 at 10:21 AM, Brendan Eich<[email protected]> wrote:
Tab Atkins Jr. wrote:
Make monocle-mustache solely use the "obj.{foo=bar}"
syntax, so that the other one is a syntax error. There's no good
reason to give devs the other type of functionality besides
completeness, and using it will almost always be a mistake on the
dev's part, I think.
Who says obj is an Object instance delegating only to Object.prototype?
Is the "setter on Object.prototype" the only observable difference
between the two?
Not for mustache, where obj can be any object, with a deep prototype chain,
setters declared via ES5-standard syntax (no definePropert{y,ies}), or
created by an OOP library.
As Allen points out, classes will (let's hope) allow easy declaration of
deep chains too.
Beware scenario-solving in an all-or-nothing way. There's no absolute good
here, and while people may (due to Prototype's Object.extend) want = not :
in most cases, that doesn't mean : is unnecessary.
I'm not making the assumption that "obj" in the examples is
necessarily an Object with Object.prototype. It's irrelevant to the
two points I'm trying to make:
1. The use-case for mustache is to replace current code that does a
lot of property-assigning statements with a more concise expression.
2. Devs will generally be surprised by [[DefineOwnProperty]] behavior,
since it's not observably different from [[Put]] in current code
except in some degenerate cases that aren't seen in non-adversarial
scenarios.
I would also assert that there's not a strong use-case for giving
[[DefineOwnProperty]] substantially more concise syntax. (I'd agree
with a somewhat terser API than the current Object.defineProperties(),
but I don't think it needs actual syntax support.)
When you do have a deep prototype chain, with details possibly buried
deep in code that you don't want to look at, how often do you actually
want to completely replace a given property? How often is that a good
behavior that won't cause accidental bugs due to setters not being
called? We switched to [[DefineOwnProperty]] for literals to avoid a
specific attack scenario that is extremely unlikely to have an effect
on real code, because authors don't normally adjust Object.prototype
and thus don't expect anything weird to happen when they create
literals. This assumption might change with classes.
Another alternative: give up on mustache since it bends object literal
syntax past its breaking point.
If we just standardized some flavor of Object.extend (for-in based? own or
in test for properties to copy? no private names? etc.) would developers be
better off?
I think we need a chainable expression form of property assigning.
How the syntax looks isn't overly important, as long as it's chainable
and an expression. ^_^ The "chainable" part, though, probably means
that we do need actual syntax for it, rather than adding a new
function.
~TJ
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
