Re: Proposal for SVG type constructors

Hi Alex.

Alexander Adam:
> Maybe dumb question but:
> 
> >2. SVGLength
> >
> >  [Constructor,
> >   Constructor(in float value),
> >   Constructor(in short unitType, in float value),
> >   Constructor(in DOMString value)]
> >  interface SVGLength {
> >    /* ...existing SVGLength members here... */
> >  };
> 
> Is it a requirement to explicitely specify all parameters? As if not,
> then we'd get ambiguous resolve issues for new SVGLength(5) which
> could be a float or a short.

Yes, Web IDL does require this.  Extra parameters (for the long possible
one overloaded version) are ignored, though.  Passing a single parameter
would match only either the float or DOMString ones.

> As a side note as we're already on that -- I've noticed that some
> functions in some implementations do not require all parameters to
> be set however it seems that this is nowhere specified, what should
> happen in those cases?

Web IDL currently specifies that passing fewer parameters than necessary
must result in a TypeError being thrown.  If specific behaviour is
desired for leaving some parameters out, then that should be explicitly
allowed by the IDL (by overloading or by using [Optional]).

> I am thinking for example on parseXML -- what if I leave the second
> param out? Will it be taken as null or should the whole call be
> ignored?

Without a dependency on Web IDL, SVG Tiny 1.2 doesn’t have very strong
requirements on how ECMAScript host objects implements its interfaces
should behave.  I would say that behaviour is defined for when two
parameters are passed, but not for any more or fewer.

If implementations generally do support omitting that second argument to
parseXML(), then SVG.next should explicitly define that, e.g.:

  interface SVGGlobal {
    …
    Node parseXML(in DOMString data, [Optional] in Document contextDoc);
  };

> Frankly, I am very uncertain whether constructors do really make
> sense.

Why is that?

> Why not extended existing stuff like you mentioned that the PathSeg
> Factories already have constructions parameters, why not using them on
> the other factories too instead of introducing just another level..
> like extending this:
>
>   >var m = document.documentElement.createSVGMatrix();
>   >m.a = a;
>   >m.b = b;
>   >m.c = c;
>   >m.d = d;
>   >m.e = e;
>   >m.f = f;
>   >p.matrixTransform(m);
> 
> Could be easily written as
> 
> p.matrixTransform(document.documentElement.createSVGMatrix(a,b,c,d,e,f))

Sure, we could support that too.  But it still seems longer than
necessary.

> Or maybe it'd be possible to make the documentElement global as well?
> That is, we could then call something like
>
> p.matrixTransform(createSVGMatrix(a,b,c,d,e,f));

At this point, it seems that a constructor would make more intuitive
sense here, IMO.

> Besides, there's another issue. We for example are not capable on
> handling constructors within Jscript / Com and Microsoft Technology
> which we require to use to interact with IE HTML so that'd be
> definitely a no-go as well.

That’s unfortunate.

> Besides, I've liked the original idea much more -- see, instead of
> writing constructors it'd be much more efficient to use the javascript
> engine's capabilities and supply anonymous property objects like
>
> p.matrixTransform({a: a, ...});
> 
> The reason is that if we supply constructors than just for this single
> call:
>
> p.matrixTransform(new SVGMatrix(a, b, c, d, e, f));
> 
> Some implementations might be required to create a rather complex
> object in memory. Instead when using the previous, javascript-object
> method, engines could optimize the call (like creating hidden class
> objects)

True, but even the new SVGMatrix object could be optimised for such
usage patterns.  If the SVGMatrix has complex functionality, then it
could be initialised only when needed.

Note that with my proposal, you can do:

  p.matrixTransform([a, b, c, d, e, f]);

as a side effect of how arrays stringify.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Sunday, 8 February 2009 23:11:12 UTC