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

RE: Allowing IDL attributes to have different types for the getter and setter

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 11 Oct 2013 17:50:49 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F9B273ACF@BY2PRD0510MB354.namprd05.prod.outlook.com>
This sounds great! I think in my long-ago message I was assuming that Object.observe-like technology would be unavailable. Or that there was a constraint that the returned value be frozen (even if the property was itself settable). I hope this gets implemented as you propose, as that's exactly how it should work!
________________________________
From: Jonas Sicking<mailto:jonas@sicking.cc>
Sent: 10/11/2013 19:34
To: Domenic Denicola<mailto:domenic@domenicdenicola.com>
Cc: Boris Zbarsky<mailto:bzbarsky@mit.edu>; public-script-coord@w3.org<mailto:public-script-coord@w3.org>
Subject: RE: Allowing IDL attributes to have different types for the getter and setter

Bringing back an old thread since we're in the process of implementing.

On Apr 18, 2013 4:21 AM, "Domenic Denicola" <domenic@domenicdenicola.com> wrote:
>
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
>
> > On 4/17/13 9:58 PM, Domenic Denicola wrote:
> > > That sounds like a bizarre API to me. Access or properties should, as much as possible, behave just like normal data properties.
> >
> > OK.  What would you like to see for the specific API under discussion here?
>
> Assuming I'm understanding the background reading correctly,
>
>     myFileInput.files = new FileList([aFile]);
>     myFileInput.files = new FileList([bFile, cFile]);

Why is that better than

myFileInput.files = [aFile];
myFileInput.files = [bFile, cFile];

I'd really like to avoid introducing new XList type for every type X
that we add to the system. Taken to an extreme we'd get sillyness like
FileListList?

In this specific case, I stick to an earlier proposal that I made elsewhere:

myFileInput.files returns a simple raw JS Array
This array can be modified using normal JS Array functions, like any
other Array can.
myFileInput.files is settable to any other raw JS Array, i.e.
myFileInput.files = ["a", 2, myFile3] works.
x = [...]; myFileInput.files = x; myFileInput.files === x; always returns true
Submitting ignores any non-Files in the Array

When exactly the UI is updated is somewhat tricky. We can likely use
Object.observe which would lead to updating at end-of-task I think.

/ Jonas
Received on Friday, 11 October 2013 17:51:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC