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

On Fri, Oct 11, 2013 at 3:39 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
> 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?

Yes. Though you could still debate if the new array should contain all
values from the previous one, or just the File values.

/ Jonas

> 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
> 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 23:16:01 UTC