Open Hixie opened 8 years ago
cc @floitschG
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.
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).
I often see people use those hash functions in Dart libraries:
https://github.com/google/quiver-dart/blob/master/lib/src/core/hash.dart
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).
An update from 2018:
VoidCallback
to dart:core also.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).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
.As of 2018, void Function()
is the same as VoidCallback
:man_shrugging:
For the hashing functions,see https://github.com/dart-lang/sdk/issues/11617
Should we just mark VoidCallback
as deprecated and convert all instances of it to void Function()
?
Why would we do that?
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
.
@lrhn had spent some time thinking about hashCode
somewhere in dart:
– I think
@lrhn had spent some time thinking about
hashCode
somewhere indart:
– I think
@kevmoo that's the issue I linked to above, #11617
@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.
Update from 2023:
double.lerp
for consistency with the many, many other static lerp
functions in Flutter's framework.double.clamp
that's much more efficient than double.clamp
. Alternatively, double.clamp
could be optimized so as to make clampDouble
unnecessary. See https://github.com/dart-lang/sdk/issues/46879.VoidCallback
would be great to add to dart:core also. It's in a dart:* library now, dart:html, but we can't depend on that from dart:ui.VoidCallback
is trivial to define at the use site. void Function()
– right?
Well it would be typedef VoidCallback = void Function();
since types with spaces and parentheses in them are something we try to avoid but the idea is to just define it once and not worry about having to redeclare it everywhere. That way you can be confident that you're really talking about the same type, it cross-links in API docs, etc. As noted earlier in this bug, using VoidCallback
has more value than not depending on dart:ui
, but it would be great to have both.
After discussion I don't think there are any signatures/behaviors that make sense to land in the core libraries. For double.clamp
and double.lerp
the core library maintainers are aligned on waiting to see whether we are able to land static extension methods as the best solution here. There are questions about whether Flutter authors prefer static extensions over the status quo, but from the Dart core library standpoint we're confident with pushing in that direction.
For VoidCallback
we're aligned on messaging a preference for void Function()
and don't have plans to add the typedef to the core libraries.
These are functions and types that we have in dart:ui (Flutter's core library) that really should just be in dart:core: