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: François REMY <francois.remy.dev@outlook.com>
Date: Fri, 11 Oct 2013 22:39:10 +0000
Message-ID: <DUB405-EAS385261BD78B35A071D0ADFFA51F0@phx.gbl>
To: Domenic Denicola <domenic@domenicdenicola.com>, Jonas Sicking <jonas@sicking.cc>
CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
What’s your proposal regarding what happens once the user uses the input to select new files after you modified the array in JS? I’m afraid you could get the operation to fail by setting a weird “length” property or changing the __proto__ of the array.

Or do you expect user interaction to “set” a new array, therefore avoiding this weird issue?

De : Domenic Denicola
Envoyé : ‎vendredi‎ ‎11‎ ‎octobre‎ ‎2013 ‎19‎:‎51
À : Jonas Sicking
Cc : Boris Zbarsky, public-script-coord@w3.org

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
Sent: ‎10/‎11/‎2013 19:34
To: Domenic Denicola
Cc: Boris Zbarsky; 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

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 22:42:17 UTC

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