New Animation System: Strings versus POJOs

Development
1

So what bothered me with the new animation system and should probably be resolved/thought about, is the fact that while some methods return some Objects (iirc makeAction), you still can’t set this Action but rather need to set it by it’s name.

That means, it’s using strings as keys, which feels very script language friendly, but in this case I don’t see the value in returning some kind of Action class, but instead maybe the key as String again.
However this feels rather wrong to me, and I’d like the keys/strings to be rather descriptive and maybe used in some kind of lookup table defined by the user/anim system, much like our node names, instead.

For everyone using a higher level system around the Animation System, storing those POJOs makes much more sense than strings. Whenever you create some Tweens (I think, it’s been a while since I last looked into it), you need to pull up some strings, even if they are random, to use the system, which I think is something we should change.

Now we’re in this bad situation that the Animation System just came out and people writing their code now would need to adopt it after this change again.

Maybe users of the Anim System can comment on this?

1 Like
2

I haven’t used the new system much, but “bad situation” sounds pessimistic to me. Why can’t we add POJO-oriented methods without breaking the current APIs?

1 Like
3

I think return types will change, so that would at least require a recompilation and then we’d may want to at least deprecate the string overloads (if we go that way for consistency), so you are right, it’s probably only a problem when users want to get their system into the “best” and “future proof” shape.