This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20407 - allow attributes to have different types for their getter and setter
Summary: allow attributes to have different types for their getter and setter
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-16 03:52 UTC by Cameron McCormack
Modified: 2012-12-30 23:23 UTC (History)
9 users (show)

See Also:


Attachments

Description Cameron McCormack 2012-12-16 03:52:10 UTC
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038362.html

Maybe syntax like:

  attribute FileList? set (FileList? or sequence<Blob>) files;

would work.
Comment 1 Olli Pettay 2012-12-16 13:37:15 UTC
Feels ugly to me. Reminds me of PutForwards.
Comment 2 Robin Berjon 2012-12-17 10:26:07 UTC
(In reply to comment #1)
> Feels ugly to me. Reminds me of PutForwards.

Is it the syntax or the feature that you find ugly? If it's the syntax, we can certainly bikeshed it, e.g.:

    attribute FileList?/(FileList? or sequence<Blob>) files;

and many other variants. But I don't think that we can dodge the fact that the feature itself represents a genuine need.
Comment 3 David Bruant 2012-12-17 10:32:34 UTC
(In reply to comment #1)
> Feels ugly to me. 

I think one not ugly way would be to have one super-type and all types used in the getter/setter use this super-type.
But retrofitting a super-type after things are already deployed on the web doesn't feel like realistic.
Comment 4 Olli Pettay 2012-12-17 10:55:48 UTC
(In reply to comment #2)
> Is it the syntax or the feature that you find ugly?
The feature. You set property to [ objectOfTypeA ], yet you
get back [ objectOfTypeB ].
Comment 5 Anne 2012-12-17 12:24:37 UTC
We already do type conversion, I don't really see how this is different.
Comment 6 Olli Pettay 2012-12-17 14:59:10 UTC
This would not be conversion, but creating new objects from the 
data passed to setter.
Comment 7 Tab Atkins Jr. 2012-12-17 17:32:13 UTC
(In reply to comment #6)
> This would not be conversion, but creating new objects from the 
> data passed to setter.

I believe Anne means that a setFoo/getFoo pair, where setFoo accepts a wider variety of things but getFoo returns a specific type, is already possible, acceptable, and widely used.  Thus, why is it unacceptable to do the same with an attribute?
Comment 8 Ian 'Hixie' Hickson 2012-12-30 05:00:45 UTC
It's even done with attributes, e.g. anywhere we use PutForwards. This just seem like a variant on that.
Comment 9 Olli Pettay 2012-12-30 14:02:35 UTC
Exactly. As I said in comment 1, reminds me of PutForwards. And some people
think (I'm certainly not the only one) that use of PutForwards is bad API design.
Comment 10 Cameron McCormack 2012-12-30 23:23:51 UTC
If [PutForwards] is bad, I would say it is due to it being not obvious what the actual property being changed is, not because it has asymmetric get/set types.