Open jdebecka opened 3 years ago
/fyi @HansMuller @goderbauer @jacob314
That's an excellent rule of thumb, although there are exceptions like ThemeData. Ideally, defining a conventional const class like Person, with copyWith, hashCode, operator == etc methods, would be regularized by using a macro definition rather than post-facto analysis.
... would be regularized by using a macro definition rather than post-facto analysis
Ah! That's an interesting insight. (fyi @jakemac53 whos' working the static metaprogramming.) Looking at the language feature doc, I notice that this might actually even be a motivating example!
Yes, any use case where a method signature and/or body needs to do something for every field in a class (or a subset matching some criteria) is probably the primary motivating use case for macros. Not only are they generally pure boilerplate code, but they are hard to keep up to date and are a source of bugs.
While we're still waiting for the metaprogramming, this rule is available in DCM https://dcm.dev/docs/rules/common/avoid-incomplete-copy-with/.
Describe the rule you'd like to see implemented
Check if all the parameters from the default constructor are included in the
copyWith
method. There's currently a bug in the TextStyle class where the package parameter can't be passed to thecopyWith
method which causes an issue when the theme is defined in a separate package.This method should have the ability to change all the parameters defined in a class and create a copy of an object with not null passed params and keep all the other properties the same.
Examples
Additional context
Issue Related