W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: [DOM4] Use new WebIDL [EnforceRange] attribute?

From: Robin Berjon <robin@berjon.com>
Date: Mon, 12 Sep 2011 12:12:56 +0200
Cc: www-dom@w3.org
Message-Id: <A9634C58-766D-4A1D-9BB0-93910F857F1E@berjon.com>
To: David Flanagan <dflanagan@mozilla.com>
On Sep 9, 2011, at 18:43 , David Flanagan wrote:
> WebIDL has just introduced an [EnforceRange] attribute that alters the behavior of numeric conversions.  I argued for something like this using CharacterData.deleteData() as an example.  In DOM Level 2, it was specified to throw a TypeError for negative arguments, even though those arguments were unsigned long and WebIDL would automatically convert any negative arguments to positive.
> 
> The last time I checked, the Webkit browsers do throw TypeError for negative arguments (following DOM 2) and Firefox converts -1 to the maximum positive unsigned long value (following the current version of DOM4).
> 
> I'd like to suggest that the arguments to this (and similar) methods be declared with [EnforceRange], which would bring DOM4 back into alignment with the intent of DOM Level 2.  If someone passes -1 to deleteData(), I think it is safe to say that they don't really mean 2^32-1.  An error is the right thing here.

I would say that if someone passes -1 to deleteData(), they might not mean 2^32-1 but they very likely mean "up to the end". Given the rarity of DOM strings 2^32 long, it's not an unreasonable conversion.

Of course if you want to delete up to the end you can always compute the correct length, but I know that that sort of code always triggers my off-by-one red flags which in turn causes me to triple check. Since we don't seem to have interoperability on the meaning of passing -1 for the length argument, I'd suggest we could claim it as pointing to the end.

Whether to further claim -2, etc. is a case that can be made, but I find it less interesting than the ability simply to point to the end.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 12 September 2011 10:13:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT