That sounds like a good idea. Do we have all the info needed at compile time
to compute the
value for a 'style' attribute?
On Jan 22, 2008 10:08 AM, P T Withington <[EMAIL PROTECTED]> wrote:
> Just some random thoughts here, comment if you have ideas.
>
> We currently have a messy situation where an attribute may be
> initialized in one of 3 ways:
>
> 1. With an immediate value
>
> 2. With a 'constraint' (which may or may not have dependencies, a
> 'path' is a special type of constraint)
>
> 3. With a 'style'
>
> Because each of these ways comes across via a different mechanism to
> the constructor, we have a really messy attempt at run time to try to
> sort out which of the 3 ways should take precedence (e.g., an instance
> may declare an immediate value and some superclass may have a
> constraint, we have to make sure the inherited constraint does _not_
> get installed and clobber the immediate value).
>
> It would be really helpful if these 3 mechanisms could be coalesced so
> that inheritance could be more easily computed.
>
> I'm thinking there should be a standard method, generated by the tag
> compiler, something like `computeAttributeValues`, that will create a
> 'master list' of the initial values of all the attributes of an
> instance. It will call the super method to get the initial values
> from the superclass and then replace the initial values that it
> overrides. The data structure that is used to represent these initial
> values will need some way to distinguish a plain value from a
> constraint and dependencies. This is probably why the constraints
> were passed via a separate mechanism.
>
> How about if we have a new runtime support class:
>
> class LzConstraint {
> var setterfn:Function;
> var dependencyfn:Function;
>
> function LzConstraint (setterfn:Function, dependencyfn:Function) {
> this.setterfn = setterfn;
> this.dependencyfn = dependencyfn;
> }
> }
>
> [This would tie in with Henry's idea to split out the computation of
> dependency functions.]
>
> If the 'initial value' of an attribute is an LzConstraint, then the
> runtime knows to install the constraint, but because all initial
> values come across in one list, it is easy to override a constraint
> with an immediate and vice-versa.
>
> Similarly, we can take the applyStyle mechanism and break it up. Each
> computeAttributeValues method can compute the styles due to the class,
> and insert them in the initial value list. If a subclass overrides a
> style with a constraint or constant value, it just needs to replace
> the superclass value in the list.
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
