brendan at mozilla.com
Wed Sep 28 14:20:51 PDT 2011
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...
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss