I think so. I will probably try to do this in 2 steps. First moving
the constraints into the attrs list, and then working around to styles.
On 2008-01-22, at 10:50 EST, Henry Minsky wrote:
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]
