- From: Cameron McCormack <cam-www-svg@aka.mcc.id.au>
- Date: Wed, 18 Jan 2006 21:07:43 +1100
- To: www-svg@w3.org
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 UTC