Make Tween<Color>, Tween<TextStyle>, Tween<Size> and so on work instead of having to use ColorTween/TextStyleTween classes

[EriKWDev]

Use case

I kind of expected Tween<Color> to work out of the box and was taken by surprise when I had to use special Classes for a bunch of types.

I'm creating an application where the user can create animations and I want basically anything to be animatable, so the application has to programmatically generate a bunch of Animations and Tweens for a bunch of different types of user created properties.

Example of some code that this has caused me to write

// Inside a Foo<T> class for my application with lots of user defined animations
// ...

Animatable<T> get tween {
    Tween _tween;

    if(beginValue is Color) {
      _tween = ColorTween(
        begin: beginValue as Color,
        end: endValue as Color
      );
    } else if(beginValue is TextStyle) {
      _tween = TextStyleTween(
        begin: beginValue as TextStyle,
        end: endValue as TextStyle
      );
    // ... and so on
    } else {
      _tween = Tween<T>(
        begin: beginValue,
        end: endValue
      );
    }

    return _tween.chain(CurveTween(curve: curve));
}

Proposal

Is there perhaps not a way to make the lerp function take objects like Color, Size and so on into account? Or maybe have the Tween<T> class be abstract and then implement all Tween<double>, (Tween<num>), Tween<'Add-Subtract-AndMultiplicableType'> separatly?

The problem lies in that objects like Color and TextStyle can't simply be subtracted and multiplied by t in the default Tween<T>'s lerp() function which is why all these separate classes have been created.

// Implementation of Tween in tween.dart
class Tween<T extends dynamic> extends Animatable<T> { 
// ...
@protected
  T lerp(double t) {
    assert(begin != null);
    assert(end != null);
    return begin + (end - begin) * t as T;
  }
}

Different approaches are of course welcome since I'm not familiar with how to implement these kind of things in such a big project like Flutter xP Maybe it would be possible to have a Tween<T extends dynamic which 'has support for subtraction, addition and multiplication'> so that only Tween<Color> and these special cases have to be implemented "manually".

[EriKWDev]

After having experimented with some ideas I've realised that ofc we can't just make Tween abstract and define every class Tween<Color> implements Tween { ... } since that causes an error ('Tween' can't implement itself).

Maybe check if T implements the method 'lerp'?

The most common pattern for all the ColorTween, SizeTween classes and so on is just calling the static lerp() method on the corresponding class.

If all classes that has a static lerp(begin, end, t) method implemented something like a Lerpable, couldn't the Tween's lerp() method check that? like so:

// somewhere
abstract class Lerpable<T> {
  static T? lerp(T? begin, T? end, double t);
}

// then Color and others can implement it
class Color implements Lerpable<Color> {
  @override
  static Color? lerp(Color? a, Color b?, double t) {
    // ...
  }
}

// in the Tween<T> class
T lerp(double t) {
  assert(begin != null);
  assert(end != null);
  // and here check if T is lerpable.
  return (T is Lerpable)? T.lerp(begin, end, t) : begin + (end - begin) * t;
}

Maybe there is a way to check that without an entire abstract class for it, but that's the gist of my new proposal.

[matanlurey]

@jonahwilliams and I looked at this on a random internal thread.

I wonder if the problem could be solved differently, that is, with less magic instead of more. Consider:

// Shortened for brevity.

class Tween<T> {
  // Add static methods for the framework-core classes (color, number, offset, size, ...?)
  static ColorTween color({Color? begin, Color? end}) => ColorTween(begin: begin, end: end);
  static NumberTween<T> number<T extends num?>({num? begin, num? end}) => ...
}

After that, the next step would be removing the default implementation of Tween.lerp (after a migration period). There would be no dynamic calls that fail at runtime, and everything would work out of the box + be extensible for other folks to provide their own (the same way it works now).

[Hixie]

(I happen to see this issue go by in the stream of recent comments; apologies for "piling on", the topic was interesting.)

If we had virtual statics we could do the Lerpable idea above, but I don't think we would, because it conflates two things -- the types, and the interpolation algorithm.

While it's not necessarily something that's immediately obvious, the question of how to interpolate two values is actually not one that can be answered just from the type alone. For example, there are two ways to interpolate Offsets in the framework -- Tween<Offset> does a linear interpolation, and MaterialPointArcTween does an arc. Similarly Tween<int> has two implementations, StepTween and IntTween. Colors are another example where people have a wide variety of opinions on how they should be interpolated; we only have ColorTween in the framework because it's significantly faster than the alternatives, but it would be reasonable for someone to create a HueColorTween that converts the colors to HSVColor and uses HSVColor.lerp, for example.

(Tangentially related, there are subclasses of Tween that aren't type-specialized, like ReverseTween<T> and ConstantTween<T>; furthemore the actual base class for Tween<T> is Animatable<T>, which has a couple of other variants, CurveTween and TweenSequence.)

So while I understand the desire to create a generic mechanism for interpolating anything, I don't think that's actually a direction that makes sense for the framework.

@EriKWDev, I'm curious to learn about how you ended up solving this problem in your application. Can you tell us more about what it ended up looking like?

(As an aside, I would caution against the idea of having a centralized location for statics "for the framework-core classes" -- this is contrary to one of the principles of our framework design, which is that the framework is not special; we don't want the API to require non-framework features to be exposed differently than framework features.)

[matanlurey]

Yeah there is no reason to have the centralized location, it would work perfectly fine without it.

In that case the change could be even simpler, just discourage (and potentially remove/make it abstract) the use of the primary Tween constructor without an override.

[Hixie]

Tween<double>, Tween<Offset>, Tween<Rect>, Tween<Size>, Tween<Radius>, Tween<EdgeInsets>, and probably many more all work fine though.

(Also I'm not sure how that would really help with the OP's problem... seems like it would actually make it worse, by removing the possibility of trying a fallback for any case that isn't explicitly implemented.)