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

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

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 18 Apr 2013 01:58:55 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF2EA18@BY2PRD0510MB354.namprd05.prod.outlook.com>
That sounds like a bizarre API to me. Access or properties should, as much as possible, behave just like normal data properties.
________________________________
From: Boris Zbarsky<mailto:bzbarsky@MIT.EDU>
Sent: 4/17/2013 21:39
To: public-script-coord@w3.org<mailto:public-script-coord@w3.org>
Subject: Allowing IDL attributes to have different types for the getter and  setter

This has come up a few times now.

Right now in WebIDL an attribute has a single type associated with it:
the setter coerces the given value to that type if it can, and the
getter returns that type.

It's not a priori obvious that this is a great fit for all APIs,
especially because of the restrictions in WebIDL on attribute types not
being sequences or dictionaries ... which are there just because
_returning_ those from an attribute would not be good.

So a question in terms of API design: from the point of view of JS API
consumers, does it make sense to have an attribute whose setter, say,
takes an array of File or Blob objects, or a single File or Blob object,
but whose getter always returns some object (always the same one) that
represents the current set of File/Blob objects we've got?  That sort of
thing is not possible to declare in WebIDL right now.  Should it be?

There's relevant discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=757664 and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20407 for those who are
interested.

-Boris
Received on Thursday, 18 April 2013 01:59:48 UTC

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