Can an annotation be overriden in Dart?

640

Annotations have no semantics in the Dart language itself, they mean what the tools recognizing them decide that they mean.

Annotations are never inherited. If you check using dart:mirrors, annotations only exist where they are written in the source code. Annotations are on declarations, not values.

So, if a tool recognizing @immutable, and it decides that the property of being "immutable" is "inherited" by subclasses, then that's that tool's decision. The immutable annotation is documented as applying to "all subtypes".

From the language perspective, there is no @immutable on MutableA, it's all in the head of the tool, so there is not annotation to get rid of. The meaning of the annotation on A is that all subclasses of A must be immutable.

The message that you get from the analyzer is a hint. You can suppress hints in various way, for example by adding an "ignore" comment before the line causing the hint. In this case, you can add

// ignore: must_be_immutable

on the line before the class declaration of the subclass which is not immutable. That should suppress the hint.

Share:
640
Ignacio Catalan
Author by

Ignacio Catalan

Updated on December 14, 2022

Comments

  • Ignacio Catalan
    Ignacio Catalan over 1 year

    Update: As a clarification by "get rid" of the annotation I mean suppressing the warnings the analyzer throws without changing anything in the analyzer itself

    I'm extending a class with an annotation and I want to override the parent class annotation, more particularly, get it rid of it. Is it possible to do so?

    For example:

    @immutable
    class A {}
    
    /// get rid of @immutable annotation
    class MutableA extends A {}
    
  • Ignacio Catalan
    Ignacio Catalan over 4 years
    Thanks for the thoroughly clarification. My question was intended for the practical purpose of somehow preventing the @immutable annotation from affecting the standard dart analyzer. If I'm writing a library, I do not want the users to have a warning from the analyzer when they are extending one of the classes provided by the library. I deduce from your answer that it is not possible to do so though. I wrapped the mutable vars with a final var as a workaround, although it's not my preferred solution.
  • Ignacio Catalan
    Ignacio Catalan over 4 years
    I think to finish answering the question, the following should be added: There is no way for the analyzer to "get rid" of the annotation other than another annotation alerting the analyzer to suppress another annotation's warning. For example if @"mutable" annotation existed, perhaps it could "override" the previous @immutable annotation. Am I correct about that?
  • lrn
    lrn over 4 years
    There is actually a way to suppress hints, because the analyzer provides one.
  • Ignacio Catalan
    Ignacio Catalan over 4 years
    It didn't work as expected, it suppressed the warning from the primary class that causes the immutable warning, but it doesn't not suppress the warning from the class that extends that class. For example warning is suppressed from MutableA, but for MutableA2 extends MutableA the warning trailing from MutableA shows up again (it has to be suppressed manually again).