Subject: Re: WG clarification request for SVG_WRONG_TYPE_ERR - msg#00012

Previous Message by Date: click to view message preview

Re: WG clarification request for SVG_WRONG_TYPE_ERR

On Thu 05 Aug 2004, Boris Zbarsky wrote: > > Jonathan Watt wrote: > >I specifically want to know > >what should happen when createSVGTransformFromMatrix is passed an object > >that is not an SVGMatrix. > > Along the same lines, what does it mean, in a weakly typed language, for an > object to be or not to be an SVGMatrix? SVGMatrix still has a defined type even in a weakly-typed language, doesn't it? I mean, if an instance can be used as (or cast as) as an SVGMatrix then it's OK. If it can't then it is an error. Or am I missing something? > What about a language in which methods can be dymically defined on objects > as needed? If I understand you correctly, then the methods are only defined on the object when they are needed, right? In this case, it should be fine, as long as the object can pass as an SVGMatrix. Dean

Next Message by Date: click to view message preview

Re: WG clarification request for SVG_WRONG_TYPE_ERR

Ian Hickson wrote: On Fri, 6 Aug 2004, Dean Jackson wrote: What about a language in which methods can be dymically defined on objects as needed? If I understand you correctly, then the methods are only defined on the object when they are needed, right? In this case, it should be fine, as long as the object can pass as an SVGMatrix. Theoretically, if you have an object implemented in Perl (e.g.), you can define it in such a way that any method call results in a lookup, the lookup being potentially arbitrary code such as asking a remote site, checking the results of a random number, etc. An object in pure Perl typically isn't explicitly labelled as being "an SVGMatrix", it just happens to act like one. Or doesn't. Or acts like one for a bit then stops acting like one half way through... This is veering off-topic fast, but there are some inacuracies here. You can indeed control method lookup in Perl, provided that a method isn't defined, using AUTOLOAD. But that isn't Perl-specific in any way, and in fact supporting a default message handler is a feature of all self-respecting OO languages (Smalltalk, ObjC...). An object in pure Perl *is* typically explicitly labelled as being "an SVGMatrix", in fact, the definition of a Perl object is just that: a reference to a variable that happens to know which class it belongs to. That being said, and to answer the original question, by default no checks are indeed performed on parameter types (though they certainly can be, it's all up to the sort of contract you may want to have). That being said, even where no checks are performed, it still makes a lot of sense to say that "an SVGMatrix" is passed because as a user of the API you promise to pass something that at least behaves like one. -- Robin Berjon

Previous Message by Thread: click to view message preview

Re: WG clarification request for SVG_WRONG_TYPE_ERR

On Thu 05 Aug 2004, Boris Zbarsky wrote: > > Jonathan Watt wrote: > >I specifically want to know > >what should happen when createSVGTransformFromMatrix is passed an object > >that is not an SVGMatrix. > > Along the same lines, what does it mean, in a weakly typed language, for an > object to be or not to be an SVGMatrix? SVGMatrix still has a defined type even in a weakly-typed language, doesn't it? I mean, if an instance can be used as (or cast as) as an SVGMatrix then it's OK. If it can't then it is an error. Or am I missing something? > What about a language in which methods can be dymically defined on objects > as needed? If I understand you correctly, then the methods are only defined on the object when they are needed, right? In this case, it should be fine, as long as the object can pass as an SVGMatrix. Dean

Next Message by Thread: click to view message preview

Re: WG clarification request for SVG_WRONG_TYPE_ERR

Ian Hickson wrote: On Fri, 6 Aug 2004, Dean Jackson wrote: What about a language in which methods can be dymically defined on objects as needed? If I understand you correctly, then the methods are only defined on the object when they are needed, right? In this case, it should be fine, as long as the object can pass as an SVGMatrix. Theoretically, if you have an object implemented in Perl (e.g.), you can define it in such a way that any method call results in a lookup, the lookup being potentially arbitrary code such as asking a remote site, checking the results of a random number, etc. An object in pure Perl typically isn't explicitly labelled as being "an SVGMatrix", it just happens to act like one. Or doesn't. Or acts like one for a bit then stops acting like one half way through... This is veering off-topic fast, but there are some inacuracies here. You can indeed control method lookup in Perl, provided that a method isn't defined, using AUTOLOAD. But that isn't Perl-specific in any way, and in fact supporting a default message handler is a feature of all self-respecting OO languages (Smalltalk, ObjC...). An object in pure Perl *is* typically explicitly labelled as being "an SVGMatrix", in fact, the definition of a Perl object is just that: a reference to a variable that happens to know which class it belongs to. That being said, and to answer the original question, by default no checks are indeed performed on parameter types (though they certainly can be, it's all up to the sort of contract you may want to have). That being said, even where no checks are performed, it still makes a lot of sense to say that "an SVGMatrix" is passed because as a user of the API you promise to pass something that at least behaves like one. -- Robin Berjon