Sdk: Functions to move to dart:core from dart:ui

[Hixie]

There are three functions (so far) that we have in dart:ui (Flutter's core library) that really should just be in dart:core:

• [ ] lerpDouble, which should really just be a static method on num:
  https://github.com/flutter/engine/blob/master/sky/engine/core/dart/lerp.dart
• [ ] hashValues and hashList, which should really be in dart:core somewhere:
  https://github.com/flutter/engine/blob/master/sky/engine/core/dart/hash_codes.dart

[sethladd]

cc @floitschG

[lrhn]

The lerpDouble function could be put on double (or num) as

double interpolate(num a, num b) => a + (b - a) * this.toDouble();

(it should return double, not num).

I'm more concerned about the hash functions.
The 373 (* 37 + x)* is a classic, so we can at least say that we are no worse than everybody else, but it's not great. It's quick, though.
We have other hash implementations spread around the source code that we could centralize and expose.

[Hixie]

Just to be clear, the algorithms used in the Flutter hash functions today are horrible; we'd love to have better ones if you take these functions over. We're planning on changing the implementations of the ones we use anyway (https://github.com/flutter/flutter/issues/859). It's the interface we're interested in moving over to core Dart, not the precise implementations.

If lerpDouble made it over that would be great. We currently have lerp functions on many of our classes (Point, Rect, Color, Border, BoxDecoration, etc) but since there's no function on "num" for it, we have to call this function instead when we need to lerp a double. Calling it "interpolate" would be fine, we'd change our functions to match (though note that "lerp" is a pretty widely used term of art).

[kasperpeulen]

I often see people use those hash functions in Dart libraries:

https://github.com/google/quiver-dart/blob/master/lib/src/core/hash.dart

[floitschG]

We discussed the lerp function, and it seems simpler if this stays a helper function. It's a common operation in drawing/3D, but is otherwise not much used. Maybe we can get it through extension methods (no promises).

[Hixie]

An update from 2018:

• https://github.com/dart-lang/sdk/issues/27791 covers moving VoidCallback to dart:core also.
• We would still love these four members moved. It would help with code that uses the Foundation library in Flutter but wants to run in non-Flutter environments like servers.
• For hashValues and hashList we still care about only the interface, and are happy with any implementation, so long as it is performant (when called and in terms of giving good hashing behaviour).
• For lerpDouble, having it be double.lerp would still be preferable IMHO but if it's just lerpDouble that's fine too. We now use lerp extensively in our API so would very much prefer that it not be renamed to interpolate.

[matanlurey]

As of 2018, void Function() is the same as VoidCallback :man_shrugging:

[dnfield]

For the hashing functions,see https://github.com/dart-lang/sdk/issues/11617

[dnfield]

Should we just mark VoidCallback as deprecated and convert all instances of it to void Function()?

[Hixie]

Why would we do that?

[dnfield]

It would achieve our goal of eliminating a dart:ui dependency where we don't want it, assuming we can live with having a void Function() signature instead of VoidCallback.

[kevmoo]

@lrhn had spent some time thinking about hashCode somewhere in dart: – I think

[dnfield]

@lrhn had spent some time thinking about hashCode somewhere in dart: – I think

@kevmoo that's the issue I linked to above, #11617

[Hixie]

@dnfield I think using VoidCallback has more value than not depending on dart:ui. I agree it would be ideal if dart:core declared VoidCallback, but it looks like that's not on the cards.