W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

Re: Request For Feedback: Traits

From: Cameron McCormack <cam-www-svg@aka.mcc.id.au>
Date: Wed, 18 Jan 2006 21:07:43 +1100
To: www-svg@w3.org
Message-ID: <20060118100743.GA17074@port.mcc.id.au>

Robin Berjon:
> The idea that all of the above could be of type "SVGMagical" and auto- 
> generate the proper access by catching the default message was  
> floated for a while, but it doesn't work because we have to also work  
> on Java, which doesn't support object-orientation :(. Javascript  
> doesn't either but it can be emulated by the back-end.

Is there anything wrong with mandating a nicer interface, similar to the
properties on all the different SVG* interfaces, just for ECMAScript?
So that you could do something like:

  someCirc.traits.cx += 5.4;

Since these are host objects, you could define that:

  - the 'traits' object's [[Get]] method, when called with an applicable
    trait name, returns an object representing the value,

  - the Length value object (for the 'cx' trait in this case) has a
    [[DefaultValue]] method that returns the length in user units when
    passed 'Number' as the preferred type hint, and

  - the Length value object also has a [[Put]] method that, when passed
    a number, sets the trait to that number as a user unit value.

That would make the statement above work.  If defined in this way, it
still avoids having many classes to implement: you just have one for
each trait type plus one for the traits object (and this could even be
on the SVGElement itself, just as TraitAccess is currently defined).

I see no reason to constraint ECMAScript to ugly method calls when it
could be made to work better.

-- 
 Cameron McCormack			ICQ: 26955922
 cam (at) mcc.id.au			MSN: cam (at) mcc.id.au
 http://mcc.id.au/			JBR: heycam (at) jabber.org
Received on Wednesday, 18 January 2006 10:08:04 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:33 GMT