- 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>
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. Philippe
Received on Thursday, 8 May 2003 14:11:57 UTC