On Jul 8, 2011, at 4:27 PM, Luke Hoban wrote:
> >>>> I agree wholeheartedly with these. In fact, I’d go further on (2), and
> >>>> say “Anything that can be done declaratively can also be done
> >>>> imperatively, using ES5 syntax”.
>
> >>The problem here is that some new syntax cannot be faked with old syntax,
> >>namely function calls, without quoting code in strings. This is not usable.
>
> I think it’s fine for the imperative solution to be less usable. That’s the
> value-add of opting-in to the ES.next syntax. And of course some (most) new
> syntax is just syntax, and the ultimate objects it creates are ones that
> could have been created using some more complex path. Those don’t need any
> library support.
>
> When Allen mentioned “imperatively”, I assumed he meant “with a library”.
> I’m not actually sure what other interpretation there would be. So I sort
> of expected that clarification to “using ES5 syntax” to be a no-op, though I
> expect it is practically quite important.
Mostly, although
obj[foo] = blah;
is also an imperative way to define a property.
Also note that my intent was to restricted both principles to matters directly
relating to objects even though I didn't explicitly mention objects in naming
the 2nd principle. There are many things in Es.next (and ES5, for that
matter) that can be done "declaratively" WRT constructing closures that has no
API based alternative (other than eval, which I choose not to count). There is
probably an argument to be made for accomplishing the somethings via reflective
APIs. However, given that there is no history of that in ES I don't think we
need to make it a Es.next requirement.
Allen_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
