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

Re: 3 comments for the 0720 DOM spec...

From: ANOQ of the Sun <anoq@vip.cybercity.dk>
Date: Fri, 14 Aug 1998 18:11:30 +0200
Message-ID: <35D461B2.EB6EB23E@vip.cybercity.dk>
To: Berlin Design <design@berlin-consortium.org>, DOM List <www-dom@w3.org>
keshlam@us.ibm.com wrote:
> 
> re point 1: Not all languages support enumerations per se. (Java's one
> obvious example that doesn't, and the C implementation is not much more
> than a self-calculating set of #defines.) I agree that in languages which
> do have this feature, and especially in those which perform typechecking on
> enums, providing the "named constants" in that form would be appropriate.
> But I'm not sure how one formally states language-specific alternatives in
> this sort of spec.

That's what the language mappings for IDL are for. There are already
mappings for C, C++, Java, Smalltalk and others. Using enum is a kind
of typesafety, which should be used if at all possible. The IDL
language mappings takes care of using them whenever possible.

> (This brings up an interesting question. If a user subclasses the DOM
> objects, are they allowed to introduce other kinds of nodes? If so, the
> enum approach would require that the enum also be subclassable to add
> appropriate nodetypes. I'm not sure which languages that support enums also
> support subclassing them. Of course if the node types are _not_ considered
> extensible, that isn't an issue.)

This might be a problem with enums - I agree. But since your unsigned
shorts are defined in Node, you are still in trouble. You have to change
the implementation of Node to add constants later and if that is an
option, it can be done for enums too.

So in short: There are no real arguments against enums right?


Cheers
-- 
,
ANOQ of the Sun / Johnny Andersen

E-Mail:   anoq@vip.cybercity.dk or anoq@berlin-consortium.org
Homepage: http://users.cybercity.dk/~ccc25861/
Received on Friday, 14 August 1998 12:21:54 GMT

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