W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

Re: Type restriction of elements in Array

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 17 Oct 2011 10:27:33 -0400
Message-ID: <4E9C3B55.8000105@mit.edu>
To: public-script-coord@w3.org
On 10/17/11 7:29 AM, Alex Russell wrote:
> Speaking only for myself (although I am a member of TC39), as JS doesn't
> allow this sort of restriction

But WebIDL sure does.

> (without proxies, anyway)

No need for proxies.  Any property with a setter can enforce whatever 
restrictions it wants on the arguments passed to that setter.

But since we're talking about "host" objects, why are we excluding 
proxies, anyway, exactly?

> it's simply non-sensical to enforce the behavior you're talking about in the
> generated JS bindings.

I don't see why that follows.

Right now, if you have a, say, ClampedUint8Array the setter will perform 
all sorts of manipulations on the argument.  Those manipulations can 
throw in various cases.  Why is it nonsensical to have some array class 
that throws in still more cases?

> APIs that use/consume these array types should be
> what throw errors.

That's a really bad antipattern where a failure is reported at a point 
far separated from where it actually happens.  Sometimes that just has 
to be, but in those cases it's a necessary evil, not a desired property.

No opinion on the proposal per se, but if we're allowing writable 
"strongly-typed" host arrays (which is what the discussion is about, as 
far as I can tell) then we do need to talk about what happens on 
assignment to them, and throwing exceptions on type mismatches may well 
be reasonable.

-Boris
Received on Monday, 17 October 2011 14:28:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC