On Sun, Oct 2, 2011 at 3:52 PM, Allen Wirfs-Brock <[email protected]> wrote:
> It's only a one character change but it eliminates the hazard that some
> people are concerned about of leaving off the .constructor or
> .constructor.{...} at the end of the pattern. Also, I can imagine that
> "recursive stache" (hey, it's inevitable that "mustache" will get
> contracted to "stache") would be useful in other situations. Personally, I
> find this new pattern not quite as "pretty" than my original proposal (it's
> less symmetric/ more irregular hence probably harder to learn and remember)
> but I'd still be happy to use it.
> If we could actually agree to this, then we could move on to making sure
> that the new operator did the right thing for non-function object and then
> we really would have a complete set of primitives that nicely and
> interoperability supported both classical and prototypal inheritance
> abstractions.
> Allen
I can see the "recursive stache" useful in some situations (although
it is another syntax addition to object literals). It would allow for
the ability to apply a deeply nested "patch" to an object, which is
sort of interesting to think about. However, what I think this
pattern, the original pattern, and Axel's pattern all lack is that it
places too much emphasis on class members, and not enough on the
prototype. Perhaps I'm being too nit-picky now, but I find that
class/static members are a whole lot more rare than prototype/instance
members. My proposal was shooting for a sweet spot where the 90% (a
made up number of course) case of a constructor and some prototype
methods could be handled in one object literal, effectively the same
code as the body of a potential class literal.
Again, if a class literal can be agreed on, my proposal is likely moot
because then we likely wouldn't need that little bit of extra sugar.
It's not a far stretch from mine to yours, I just think that if no
agreement can be made, I like my pattern better for the general use
case.
- Russ
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
