RE: Proposal for SVG type constructors

Hi there!

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.

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? 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? 

Frankly, I am very uncertain whether constructors do really make sense. 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))

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));

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. 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) 

Just my $0.02

mfG / Regards,
Alexander Adam
--
Geschäftsführer / CEO
 
examotion GmbH
Ostendstraße 115
90482 Nürnberg, Germany

Fon: +49 911 - 504901-11
Fax: +49 911 - 504901-20
 
E-Mail: alexander.adam@examotion.com
Web: http://www.examotion.com
 
Geschäftsführer: Alexander Adam
Amtsgericht Nürnberg HRB Nr.: 23803
Gerichtsstandort: Nürnberg
 

--------------------------------------------------
LEGAL DISCLAIMER: The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
--------------------------------------------------
 

> -----Original Message-----
> From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org]
> On Behalf Of Cameron McCormack
> Sent: Freitag, 6. Februar 2009 01:51
> To: public-svg-wg@w3.org
> Subject: Proposal for SVG type constructors
> 
> 
> Hello WG.
> 
> I’ve checked in my proposal for constructors for the SVG type
> interfaces:
> 
>    http://dev.w3.org/SVG/proposals/type-constructors/type-constructors.txt
> 
> Comments welcome.
> 
> Thanks,
> 
> Cameron
> (ACTION-2443)
> 
> --
> Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 6 February 2009 08:06:54 UTC