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

While there are no hard and fast rules, I generally prefer for read/write attributes (which go under various names in various languages) to model a  read/write state variable  Setting an attribute may have side-effects but in general the last value that was stored into an attribute should be the value that is retrieved  if the value is immediately read.  If you use attributes this way then its appropriate for a single type of be associated with both setting and getting the value.

Note that for JS fulling this rule means that the choice of using a data property or an accessor property in many cases can be viewed as an implementation detail with an accessor being necessary only if side-effects are involved or perhaps to support some system design considerations.

If you want to have an attribute value that is derived from some other kind of object or perhaps from a set of options, then I would represent it as a get only attribute and I would define one or more methods that have the side-effect of modify the getable value of the attribute.  That way it's clear that something is going on rather than just setting and retrieving a simple value.

This is a general design principle that I would employ in pretty much any language or environment unless that were pre-existing system consistency reasons for doing otherwise.  I'm don't really know the full spectrum of web platform APIs well enough to know whether that consistency exception applies here.

Allen



On Apr 17, 2013, at 6:38 PM, Boris Zbarsky wrote:

> 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 02:25:05 UTC