I particularly like your code annotations, with notes such as // 1 in the code keyed to the related description in your text:
A widget’s build() method is the entry point for composing together other widgets to make a new widget.
You have a wonderful opportunity to do a similar annotation for an annotation that appears everywhere and that the official Dart documentation doesn’t manage to clarify:
Nobody seems to have mentioned, in a clear way, the motivation (and the tradeoffs) behind @override.
Search for @override in your book and you’ll get 82 results. Unfortunately, all of them are occurrences of the annotation and, as far as I can tell, there’s not a single annotation regarding why.
In any case (whether @overridemust be explicit or could be implicit), please consider providing a good description of the concept before the first appearance of @override in section 2 (Hello, Flutter).
Thanks for your consideration, @funkyboy. That will make your book unique in the Flutter industry. The idea is quite simple but, somehow, quite elusive:
Describe a concept before using it.
Euclid did it. Go for it!
I really appreciate the link to your Dart book.
My best to you and all of your colleagues, who are obviously working hard and with enthusiasm to benefit the rest of us.
Ok. Here’s some info on @override straight from the source of truth for Dart:
To find both @override and overriding on this web page, search for the partial word:
overrid
This info is good but you have to dig for it and search for it explicitly. As one of my physics professors used to say: You have to know everything before you can do anything.
I still believe that you have the golden opportunity to do a superb job introducing and clarifying this concept before using it (or, following your annotation style, as you use it).
For the curious: I’m still @panchoybook but I have a new account, due to some bureaucratic labyrinths having to do with non-first-class citizenship. Problem solved.
