Well I guess the design of this depends on how complicated you want to allow the animations to be.
Indeed, this is the big question. Do we want animations to be in stages? What if one property has a long animation and another needs to be in two short stages?
Also it occurred to me that matrix interpolation might work better in layers, but that might be a little too advanced to consider. I was thinking along the lines of wanting to move outward from a center while rotating, for a kind of spiral effect. Probably pointless to bother with.
My current best idea is to do something very flick-like, and have the all be animate(src, result, time), where the result is an Appearance. This would effectively change src's Appearance but tell the client to transition to that over time from its current state. Multiple calls could represent stages. The beauty of this is that it can handle a lot of var changes at once, and it's really straightforward. The downside is it requires the user to make a temporary copy of the object to set all those vars first, unless it's provided with a parameter list in place of an Appearance.
I don't think your examples that call it per-property are necessarily the best choice, inasmuch as 1) they'd be subject to timing issues, and 2) it's extra network overhead. I do like the way you built in stages, though.
You could do something similar to jQuery's animate(). Or maybe something similar to my first suggestion but instead of having the property argument, make from and to associative lists (which I guess would be pretty similar to jQuery except you provide explicit starting values).
That's relatively close to my animate() idea, with a parameter list. (The main issue I see with a parameter list is that with atom.transform being a list, converting to and from a parameter format is kind of ugly.)
Personally I still kind of like the way my second and third examples work. Mainly because I can't think of another method that would allow all of the same features without overcomplicating the code. It is simple and easily readable yet reasonably powerful. It doesn't introduce any new syntax or require specially formatted strings. Most of all, it doesn't require multidimensional lists, which could get ugly. Additionally, it doesn't require any new datums. I actually think adding a /animation type might be a good way to do this, but in the past you guys have seemed reluctant to add built-in datums for things like this.
Yeah, something similar to a datum would seem to make more sense, but I'm definitely reluctant to build one in.
One call per var could potentially get repetitive, but it looks like there will not be many vars that can be animated, and of those, I would expect that in most cases, only a couple are being animated at once. So hopefully, that wouldn't be an issue. And animating many vars at the same time will probably require more code no matter which way the proc works.
Yeah, you make a good point there. I'd just rather avoid multiple proc calls, which would mean multiple messages, for animations that need to happen concurrently.
Then again, maybe animate(src, ..., time) would work with an argument list, where you could say something like:
animate(O, alpha=0, transform=list(2,0,0,0,2,0), 10)
The 10 is a time argument, which could be named too or left unnamed; the first argument is of course the object to be animated. Its vars are changed immediately as a result of the call, but first the clients are told to animate from the current appearance to that.
The transform argument may look a little awkward there because I haven't settled on a helper function format yet (see id:1353302), but that says to scale by 2.
Mind you this doesn't address a case where you might want an atom to spin around 10 times. The transform matrix would be identical to the identity matrix, which means you'd want to do something with stages. Stages could be handled by multiple calls. Maybe that'd be ugly, but I think it'd be okay.
You could do something similar to jQuery's animate(). Or maybe a proc like my first suggestion but instead of having the property argument, make from and to associative lists (which I guess would be pretty similar to jQuery except you provide explicit starting values). The downside is that you lose the ability to add a more steps to the animation, unless you allow the proc to be called multiple times and queue the animations. In that case, you lose the ability to loop a multi-step animation.
Personally I still kind of like the way my second and third examples work. Mainly because I can't think of another method that would allow all of the same features without overcomplicating the code. It is simple and easily readable yet reasonably powerful. It doesn't introduce any new syntax or require specially formatted strings. Most of all, it doesn't require multidimensional lists, which could get ugly. Additionally, it doesn't call for any new datums. I actually think adding a /animation type might be a good alternative, but in the past you guys have seemed reluctant to add built-in datums for things like this.
One call per var could potentially get repetitive, but it looks like there will not be many vars that can be animated, and of those, I would expect that in most cases only a couple are being animated at once. So hopefully, that wouldn't be an issue. And animating many vars at the same time will probably require more code no matter which way the proc works.