Design principles for extending ES object abstractions

Allen Wirfs-Brock allen at
Fri Jul 8 16:47:21 PDT 2011

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 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 (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 requirement.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list