W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2003

Re: DOMConfiguration interface

From: Philippe Le Hegaret <plh@w3.org>
Date: 08 May 2003 14:11:55 -0400
To: Caroline Rioux <crioux@decisionsoft.com>
Cc: WWW DOM <www-dom@w3.org>
Message-Id: <1052417514.32672.181.camel@jfouffa.w3.org>

On Thu, 2003-03-27 at 05:22, Caroline Rioux wrote:
> I have some concerns about the DOMConfiguration interface that was 
> recently introduced in DOM Level 3.  
> After implementing an old version of the spec,
> (http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20021022/core.html#DOMConfiguration)
> containing different method signatures for boolean parameters (ie 
> setBooleanParameter, getBooleanParameter), I was suprised to see that the new spec 
> does not distinguish between features and regular parameters, and considers them 
> all to be DOMUserData.  
> In a C++ implementation, for example in xerces-c, one would have to rely on 
> void *, which is not particularly type-safe without the use of RTTI. It 
> also means one cannot distinguish between int and bool, since both are 
> integers in C++.
> I don't understand why the interface relies on DOMUserData, when types for 
> all underlying parameters are defined.  Wouldn't it be preferable to have 
> specific methods like 'void setErrorHandler(DOMErrorHandler handler)', for 
> the parameters and 'void setBooleanParameter(DOMString feature, boolean 
> flag)' for features, so that they could be type safe?  I understand that 
> expandability is an argument for the current interface, and I could 
> understand that a non-type-safe method could be provided, but I am not 
> overly comfortable with the 'cast and hope' scheme. :-)

Unfortunately, we decided for expandability and acknowledged that
non-RTTI implementation will not be able to implement those methods
appropriately. However, it is important to note that, for the ECMAScript
binding, we decided to allow the parameters to be attributes of the
DOMConfiguration interface as well. The C++ binding can certainly limit
the same solution to avoid the "cast and hope" scheme issue.

Received on Thursday, 8 May 2003 14:11:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:11 UTC