W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: FileList (and other Array-like types)

From: Robin Berjon <robin@w3.org>
Date: Thu, 30 May 2013 16:46:26 +0200
Message-ID: <51A76642.5090709@w3.org>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: Jonas Sicking <jonas@sicking.cc>, public-script-coord@w3.org, Arun Ranganathan <arun@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>
On 30/05/2013 16:19 , Boris Zbarsky wrote:
> On 5/30/13 5:41 AM, Robin Berjon wrote:
>> This includes mutating them, and
>> behaving sanely in the face of mutation.
>
> A question is what constitutes sanity.

Which is why I brought it up :)

>> I'm very partial to C. The 5 should get pushed onto the array, and
>> whenever I look there in future it should still be right there, but any
>> control that is reflecting the status of that array should just ignore
>> it.
>
> As opposed to just throwing an exception and being broken?  That might
> be expensive to do.

I reckon that depends on where. I somehow doubt that making FileList 
behave like an array with UI binding would be all that expensive, but I 
guess it could be the case with other uses of live lists.

My point is that things that are arrays should be arrays as much as 
possible  the alternative is maddening. Ideally, that would include not 
blowing up when putting something into them. But if there is good reason 
to throw on invalid values, then so long as for all other purposes it's 
an array that's viable.

Throwing is also better than silently not pushing the value (as opposed 
to putting it in the array but ignoring it for behaviour). That sort of 
behaviour leads to strange debugging experiences.

>> All the libraries that do data binding (e.g. Angular, KnockOut) will do
>> something like that.
>
> What do they do if you push bogus values into the array?

As you might expect, there are as many different behaviours as are possible.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 30 May 2013 14:46:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC