On 2010-05-25, at 13:22, Max Carlson wrote:
>> 2) Rather than creating multiple object hashes for the various animation
>> attributes, why not define a class (data structure) that holds all the
>> animation properties of an attribute? Thus, when animating an attribute,
>> you will just say something like:
>>
>> var aas = this.__animatedAttributes;
>> if (! aas[name]) { aas[name] = new AnimationAttribute(start, end, ...);
>
> I was thinking instead of doing this, I'd keep a hash of animators - so we
> won't need to create a new one each time LzNode.animate() is called. I'm
> going to save this for another change.
It seems silly to get this far into re-modularizing this and not to do it right.
I think André's and my point is, that we are creating a boatload of new objects
on each node to support animation. There really should just be one object for
each animated attribute. You could have one massive table that looks up by
nodeID + attribute, but I'm ok with having a per-node table. Just not per-node
X per-animation-state-var tables.
Maybe my hypothetical new object should be called AttributeAnimator and should
hold all the animation state for the attribute and have methods for
reset/stop/start/pause/resume/step, etc. That is, write this code actually as
object-oriented code?
