W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2002

Use of "unsigned" for non-enumeration values

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Thu, 28 Mar 2002 16:33:51 -0700
Message-ID: <4D62A7266F41D611B92C00E018C1C19C0DD4E8@thor.aeathtl.com>
To: "'www-dom@w3.org'" <www-dom@w3.org>
Except when there is need for that extra bit of range, it seems undesirable
to make integer arguments or writable attributes that are not enumerations
"unsigned".  It doesn't matter in Java or JavaScript, since neither supports
the concept of unsigned numbers.  It does, however, make implementations in
other language either fail differently or incorrectly succeed, since C and
C++ will transparently convert a negative signed number into a large
positive number.

Obviously, it is too late to change the existing L2 and below methods, but
we should avoid adding any more problems.

There did not seem to be any examples in Core, Load/Save.

In ASLS:

minOccurs and maxOccurs in ASModel.createASContentModel()
ASObjectList.length 
ASObjectList.item(index)
ASNamedObjectMap.length
ASNamedObjectMap.item(index)
ASContentModel.minOccurs
ASContentModel.maxOccurs
CharacterDataEditAS.*(offset,count)

In Xpath:

XPathResult.snapshotItem(index)
XPathResult.snapshotLength   
  not really necessary since it is read-only, but for consistency

In none of these cases does it appear that range is an issue.  Java and
Javascript implementions will have to raise an appropriate exception when
negative values are passed.  Encouraging other bindings that support
unsigned numbers to silently treat negative values are large positive values
isn't beneficial.

Using signed values for maxOccurs would have the benefit of allowing the
more accessible -1 to be used for "unbounded" instead of Integer.MAX_VALUE.
Received on Thursday, 28 March 2002 18:33:21 GMT

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