On Sep 28, 2011, at 1:53 PM, Dean Landolt wrote: >> Same here, but in comma-first it's not always adjacent: >> >> var middleware = [ context, >> , csrf >> , xsite >> , head >> , considtional >> , error >> ] >> >> You've got to squint a little to see that hole, right? > > That is horrible, and a reason to reject comma first. > > Unless this syntax were stricken from the language, of course :)
Won't help the downrev browsers in three years, so while it helps in the long run, the comma-first still is to be avoided in the mean while. IMHO. > Which is why I was suggesting holes be explicit -- perhaps a new type A new type refracts through the entire runtime semantics. Holes are nowhere near a strong enough use-case to motivate yet another undefined-y type (as if null == undefined weren't enough!). > In order to avoid a runtime compatibility break it would have to be a subtype > of void 0. After thinking it through a bit this would be tough to do without > introducing yet another type system. So yeah, not worth it for this rare edge > case... Whew! > One final point: if its worth having holes at all (and IMHO it is) we > definitely need more API surface to work with them from userland. This means, > at the very least, we need a way of finding where holes start that's better > than O(N). Agreed -- I want a thousand github flowers to bloom. Do not want TC39 designing APIs and pushing them into standards if we can adopt winning ones from the developer community. /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
