On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
> On Tue, May 29, 2012 at 9:45 AM, Mark S. Miller <[email protected]> wrote:
>> The use of foo:bar in object literals and in JSON
>> causes [[DefineOwnProperty]] behavior, not [[Put]] behavior. Making
>> mustache's treatment of foo:bar inconsistent with object literals and with
>> JSON is a worse footgun. If you always want mustache-with-[[Put]], use "="
>> rather than ":".
>
> If it's desperately important that we don't make "obj.{foo:bar}" do a
> [[Put]], then it would be much better to simply not allow that syntax
> *at all*. 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.
That are a lot of other use cases for Object extension literals. See the
proposal for some examples. If you only allow "foo=bar" you loose them.
Language design and extension is a complex process. Being supportive of
multiple use cases generally makes a new feature more valuable and more likely
to be adopted. It also makes for smaller, more consistent languages.
Socially, support of multiple use cases helps a feature achieve consensus
support. A "mustache" proposal that only allows "foo=bar" may not do enough
to get the support behind it that is needed to make the cut. Neither might a
proposal that lacks "foo=bar". The fact that there are multiple perspectives
isn't bad, and it doesn't mean that we are "designing by committee". It is
simply how language design works.
Finally, I'm skeptical of any self-styled representation of "normal developers"
that isn't backed up with data. In particular, on this other proposals I
generally receive "community" feedback that span all perspectives on the
issues. (BTW, on the proposal in question, the positive feedback seems to be
running quite a bit ahead of the negative). At least some of it seems to come
from relatively "normal programmers" (although I have no idea how anybody would
actually define that term). I'm familiar with the issues you raise, their
general theme is something that we routinely discuss in TC39 (and really in any
competent language design team). You really hould assume that we have
considered and factored them into our proposals. It is perfectly fair, try to
demonstrate why we made the wrong trade-offs in a proposal but this will seldom
work if you only consider one dimension of the design. Try to be the most
comprehensively reasoned voice, not the loudest.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
