Re: WG clarification request for SVG_WRONG_TYPE_ERR

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.

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 Sunday, 8 August 2004 13:56:31 UTC