W3C home > Mailing lists > Public > www-svg@w3.org > October 2000

Re: idl

From: Jon Ferraiolo <jferraio@Adobe.COM>
Date: Tue, 24 Oct 2000 09:11:36 -0700
Message-Id: <4.2.2.20001024090943.00cbe440@mailsj.corp.adobe.com>
To: Stephane Conversy <conversy@emn.fr>
Cc: www-svg@w3.org
At 02:53 PM 10/24/00 +0200, Stephane Conversy wrote:
> > The SVG IDL was made to copy the techniques used by IDLs in other W3C
> > specifications. The main reason the SVG IDL doesn't use enumerations is
> > that the other specs don't use them either.
>
>That's to bad since enumeration are a way to catch type errors when setting
>an attribute, or calling a method.
>
> > The lack of enumerations in
> > Java and JavaScript is probably why all W3C spec don't have enumerations in
> > their IDLs.
>
>And that's much too bad since enumeration  are easily translated in short int
>when they are not handle by a language.
>Anyway, I can cope with that.
>
>However, there some strange stuff from place to place in the idl.
>For example, there is a 'NumberList' interface, which can be used
>in an interface that owns, well, a list of number. But there is no
>DOMStringList, thus the SVGTests interface uses a nuntyped List, which is said
>
>in the RFC to handle 'only DOMString'.
>It's the same for SVGTextRotate(List angles) or AnimatedPathData...
>
>What is the reason behind that ?

There will be fixes to the IDL in these areas in a soon-to-be-released 
revised version of the Candidate Recommendation specification. Implementers 
pointed out problems with these interfaces in email to this list a couple 
of months ago.

Jon


>Thank you.
>
>     stef
Received on Tuesday, 24 October 2000 12:12:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 November 2012 23:52:48 GMT