Re: WG clarification request for SVG_WRONG_TYPE_ERR

On Sun, 8 Aug 2004, Robin Berjon wrote:

> 
> Jonathan Watt wrote:
> > I would like to throw SVG_WRONG_TYPE_ERR. Having said that, as Boris
> > pointed out to me previously, it doesn't seem to make sense to say that
> > you can only pass in an object of type A, but also to say an error should
> > be thrown if what was passed in wasn't of type A.  In a strongly typed
>  > language, that situation can't arise.
> 
> Depending on the type matching system's expressiveness, in some cases it 
> could. For instance, a method might equally well accept a Text node or 
> an Element (eg appendChild) but in many "strongly typed" languages, you 
> could only match on a common ancestor, in this case Node. An attempt to 
> pass in an Attr node would be caught at runtime.
> 
> > In a weakly typed language, the
> > distinction doesn't exist. If we follow this logic there's no reason for
> > SVG_WRONG_TYPE_ERR to exist, but I'm not quite sure what's meant by "type"
> > in ECMAScript. Also the spec doesn't define exactly what is meant by "is
> > the wrong type of object".
> 
> That would be quite impossible to do while not being shot by hordes of 
> programmers and computer scientists, no matter which definition we came 
> up with.
> 
> In some languages you'll see that it's not labelled with the proper type 
> or a proper descendant, and flag a wrong type. In other languages you'll 
> try to call a method that must be there if it's of the advertised type, 
> but isn't, and throw the same error.
> 
> I'm not sure that's satisfactory to you though?
> 
> > Nevertheless, although I'm still thinking about
> > this, my current opinion is that since ECMAScript objects can morph as
> > pointed out, implementations will require objects passed into many methods
> > to be their own implementations of the SVG interfaces concerned. Perhaps
> > SVG_WRONG_TYPE_ERR should then be thrown if objects are not the UA's
> > implementation?
> 
> I'm not sure what you're proposing (well, perhapsing). Is it:
> 
>   a) if the object is implemented by the UA (leaving aside definitions of
>      what the UA is), and it isn't the right type, you throw a SWTERR,
>      and if it isn't implemented by the UA, and doesn't correspond to the
>      proper type in the languages possibly loose definition, you throw a
>      different exception.
> 
>   b) the same for UA objects, but user-implemented objects get the same
>      exception.
> 
>   c) only UA objects are allowed to be passed to those methods.
> 
> Having to chose between (a) and (b) I would prefer (b) because it is 
> more consistent, and is conducive to sticking to what users expect. I 
> think (c) is not an option at all, as it would break existing code that 
> creates Ecmascript objects in place, something that's widely used for 
> event handlers and namespace resolvers.

I was "perhapsing" (c) - see my previous email for an explaination.
Personally I doubt that there is a huge amount of code for SVG out there
that that would break, but I could be wrong. I agree it would be better
not to place such a restriction, but the other option is that Mozilla will
never throw SVG_WRONG_TYPE_ERR. I don't see any good solution to this. 

Anyway, I'm away on vacation for 3 weeks so I'll have to pick this up
after I get back. Thanks for the input so far everyone!

> A guiding rule that I would use is that when someone uses a programming 
> language to manipulate SVG (or other vocabularies) they are seeing the 
> world from the view point of that language, and that is not something 
> that we should constrain. Both (a) and (c) go against the grain of what 
> one would expect when using Ecmascript.
> 
> -- 
> Robin Berjon
>

Received on Wednesday, 11 August 2004 18:46:03 UTC