Skip to content

Conversation

@LongCatIsLooong
Copy link
Contributor

@LongCatIsLooong LongCatIsLooong commented Aug 28, 2019

Description

make CupertinoDynamicColor's constructors const, in order to use a CupertinoDynamicColor as the default value of a function argument. This change would allow us to provide a default CupertinoDynamicColor in the constructor of the following widget, without breaking its current API:

class SomeWidget extends StatelessWidget {
  const SomeWidget({ Key key, this.color = defaultColor }) : super(key: key);
}

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I signed the CLA.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I updated/added relevant documentation (doc comments with ///).
  • All existing and new tests are passing.
  • The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
  • I am willing to follow-up on review comments in a timely manner.

Tests

No new tests were added: existing tests should be able to cover this.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

  • Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
  • No, this is not a breaking change.

@fluttergithubbot fluttergithubbot added f: cupertino flutter/packages/flutter/cupertino repository framework flutter/packages/flutter repository. See also f: labels. labels Aug 28, 2019
: CupertinoUserInterfaceLevelData.base;

Color resolved;
switch (brightness) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was expecting a much larger switch statement

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah with only eight possibilities (at least for now) it isn't too bad. It is a bit verbose, but I think it gains a lot in clarity.

Copy link
Contributor Author

@LongCatIsLooong LongCatIsLooong Aug 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am scared of enums and switches, especially when the enum has a name like CupertinoUserInterfaceLevelData

Copy link
Contributor

@justinmc justinmc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

It's great that you were able to make this const. Did you find that it needed to be const for some reason or are you just doing it because it's possible?

elevatedColor,
darkElevatedColor,
highContrastElevatedColor,
darkHighContrastElevatedColor,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a lot more clear 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Nice!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏

highContrastColor: color2,
darkHighContrastColor: color3,
));
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comma here?

@LongCatIsLooong
Copy link
Contributor Author

@justinmc default values have to be const values, if a widget's constructor has a color parameter with a default color, it can't take a CupertinoDynamicColor as the default value if CupertinoDynamicColor doesn't have a const constructor. I was converting cupertino widgets and realized that CupertinoDynamicColor being not const constructible is going to break quite a few widgets' current API so I came back and changed it. I had to call the super constructor with a dummy value though:

assert(highContrastElevatedColor != null),
assert(darkHighContrastElevatedColor != null),
assert(_effectiveColor != null),
super(0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A // comment that refers to the value getter would be useful here.

}(), 'The colorMap provided is invalid: $_colorMap'),
super(value.value);
@override
int get value => _effectiveColor.value;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NICE

resolved = isHighContrastEnabled ? highContrastColor : color;
break;
case CupertinoUserInterfaceLevelData.elevated:
resolved = isHighContrastEnabled ? highContrastElevatedColor : elevatedColor;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add a perfunctory break here

if (identical(this, other))
return true;

return other.runtimeType == runtimeType
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe check for identical(this, other) first?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It already does.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, yes it does! Hazards of looking through the github review microscope.

// Fallback System Colors, extracted from:
// https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors
// and iOS 13 beta.
const CupertinoSystemColorsData _kSystemColorsFallback = CupertinoSystemColorsData(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is entirely safe. Not sure if developers should expect it either (we're not documenting this case). If resolved.runtimeType != value.runtimeType do we still want to do this? Seems like it would be easier to understand the semantics of thie method if we unconditionally returned a CupertinoDynamicColor (not a subclass).

Copy link
Contributor

@darrenaustin darrenaustin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Nice update. Having a const constructor for a class like this is helpful and the changes to the color storage are a lot easier to follow.

elevatedColor,
darkElevatedColor,
highContrastElevatedColor,
darkHighContrastElevatedColor,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Nice!

: CupertinoUserInterfaceLevelData.base;

Color resolved;
switch (brightness) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah with only eight possibilities (at least for now) it isn't too bad. It is a bit verbose, but I think it gains a lot in clarity.

@LongCatIsLooong LongCatIsLooong force-pushed the const-constructible-dynamic-color branch from 823fa8c to 2ab56b8 Compare August 28, 2019 22:17
Copy link
Contributor

@HansMuller HansMuller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@LongCatIsLooong LongCatIsLooong merged commit 98b9f31 into flutter:master Aug 29, 2019
@LongCatIsLooong LongCatIsLooong deleted the const-constructible-dynamic-color branch August 29, 2019 23:40
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

f: cupertino flutter/packages/flutter/cupertino repository framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants