Repository navigation
Conversation
…esn't exist in Dart 2.
googlebot
added
the
cla: yes
| [`setState()`](https://docs.flutter.io/flutter/widgets/State/setState.html) | ||
| and thus marking itself dirty. That is why if you look at the dump you | ||
| will see that specific object marked "dirty". You can also see what | ||
| see that specific object marked "dirty". You can also see what |
There was a problem hiding this comment.
Since this is a conditional (has "if you"), shouldn't it be "would" instead of "will"?
As in "That is why, if you looked at the dump, you would see that..."
Or, if you don't want the conditional, it should be "This is why, when you look at the dump, you see that..."
There was a problem hiding this comment.
I suppose it's grammatically correct either way. I think I like the last one best, without the "if".
| RegExp regExp = RegExp(p); | ||
| RegExp regExp = RegExp(emailRegexp); | ||
|
|
||
| return regExp.hasMatch(em); |
There was a problem hiding this comment.
Good coding practice would have this em renamed to something like emailString. em isn't very descriptive...
| mode. This is the default if you use `flutter run` or the bug icon | ||
| in Android Studio. Some tools support assert statements through the | ||
| command-line flag `--enable-asserts`. In this mode, | ||
| Dart `assert` statements are enabled, and the Flutter framework performs |
There was a problem hiding this comment.
There is a danger that this could be misunderstood: 'performs runtime checks verifying that invariants are not being violated' sounds like we are checking language invariants (like heap soundness: "A variable of type T will never refer to an instance that cannot be typed as a T (but it can be an instance of a subtype)"), but language invariants are always maintained in Dart 2, not just when we run a program with --enable-asserts.
(OK, nobody talks about "trust-something" execution, and I'm pretty sure that we shouldn't mention it here, so we don't. ;-)
The only thing controlled by the --enable-asserts option is whether user-written assert statements are (1) ignored or (2) the argument is evaluated, and if false an AssertionError is thrown.
I don't know how to get the style right here, but maybe we could have something like 'In this mode, Dart assert statements are enabled, and the Flutter framework will then evaluate the argument to each assert statement encountered during execution, and throw if the result is false. This allows developers to enable or disable invariant checking, such that the associated performance cost is only paid during debugging sessions.'
|
@eernstg, @gspencergoog, please check the updated version. thx |
|
I'm still adjusting to Cirrus. @chalin, can you explain why the tests are failing? |
It is an issue with the container image I believe. We'll need to get that resolved (separately) first. |
|
As I've mentioned elsewhere, I've reinstated Travis builds for now. Rebase/merge to pickup the changes. |
|
No response = tacit approval. ;) Merging. Please open a new issue if you have other feedback. |
|
Sorry, didn't see the request for comments—approval now untacified! ;-) |
6 participants
Please review, @Hixie.