Re: Request For Feedback: Traits

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