Uninteresting parameters

[Brendan Eich]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110928/62e50be3/attachment.html>