Thanks for your PR! I'm very sorry I didn't reply to you sooner. While I think ignoring fields is an interesting possibility, I wasn't sure about the direction this goes into. On the one hand, functional_data was intended for immutable data objects, while on the order hand, trying to be minimally restrictive in what you can do with the class. So I've been in doubt whether to annotate the generated "mixin" with @immutable instead of ignoring warning that classes that implement operator== and hashCode should. That would, of course be a backwards incompatible chance, breaking code like yours with a mutable cache value.
About the implementation: Using an implementation of Equality (that is, Ignore) as an annotation feels a bit dirty. Better would be a dedicated annotation that is extendable with other options later on. Something akin https://pub.dev/documentation/json_annotation/latest/json_annotation/JsonKey-class.html. So far, Field is the best I could come up with. So there would be @Field(ignore: true) and @Field(equality: MyEquality()) as replacement of @CustomEquality(MyEquality()).
Thanks for your PR! I'm very sorry I didn't reply to you sooner. While I think ignoring fields is an interesting possibility, I wasn't sure about the direction this goes into. On the one hand, functional_data was intended for immutable data objects, while on the order hand, trying to be minimally restrictive in what you can do with the class. So I've been in doubt whether to annotate the generated "mixin" with
@immutableinstead of ignoring warning that classes that implementoperator==andhashCodeshould. That would, of course be a backwards incompatible chance, breaking code like yours with a mutable cache value.About the implementation: Using an implementation of
Equality(that is,Ignore) as an annotation feels a bit dirty. Better would be a dedicated annotation that is extendable with other options later on. Something akin https://pub.dev/documentation/json_annotation/latest/json_annotation/JsonKey-class.html. So far,Fieldis the best I could come up with. So there would be@Field(ignore: true)and@Field(equality: MyEquality())as replacement of@CustomEquality(MyEquality()).