@protected should be listed next to "inherited"

[Hixie]

For example, look at:
https://docs.flutter.io/flutter/material/NavigatorState-class.html

It's not clear from that which methods are protected and which are public. It would be nice if next to where it says "inherited", we could add other annotations like "protected".

[jcollins-g]

I have a prototype of generic annotations support in this field working now. It currently takes all annotations, as well as 'const' and 'final', and adds them to the italicized "feature" area. Custom annotations include a hyperlink to the definition of the annotation.

It seems to work well enough, but before I polish it I could optionally make some changes:

• Whitelist certain annotations and only display those? (and which ones if so?)
• Is adding const/final useful? Maybe take that out.
• Change the order of feature display if we decide we like certain features first (currently, I sort them alphabetically)

@keertip @devoncarew

Thoughts?

[keertip]

@jcollins-g , could you post an image with the changes?

• Not keen on whitelisting as how would we decide which ones to show? There will always be someone whom we cant satisfy if we do it.
• We do want to show const/final, it is useful. Maybe show it differently? Change the order as you suggested.

[Hixie]

const might be useful. final is already there (as "read-only").

[jcollins-g]

If it's not possible to define something that is "read-only" but isn't also final, we should probably collapse final / read-only into one indicator. My inclination would be "final" as that's the actual language construct involved.

Just to throw a dart at the the board for ordering...
[inherited] [annotations] [const] [final] [read/write/both]

Screenshot of what my current code does.

[sethladd]

IIR, we originally went with "read-only" because that meant "there's no setter", but in the case of a getter, the getter can return a different value on every call. Not sure that replacing "read-only" with "final" would imply the same thing, because if we use the word "final" instead of "read-only", people might think that the property is always the same value.

[jcollins-g]

@keertip I didn't know whether or not it might be common in some code to have a half-dozen custom annotations per method or similar, which is why I wondered. Will go without whitelisting.

As a Dart novice I wasn't sure if if final/read-only were intended to be exactly that same, but that makes sense @sethladd.

I wrote some example code to return random values from a getter, but the Element (from the analyzer?) seems to return true for isFinal in that case. This is causing isFinal to return true here in the Field class: https://github.com/dart-lang/dartdoc/blob/master/lib/src/model.dart#L870. It seems that the ModelElement class forces isFinal to be false regardless of what the element says (https://github.com/dart-lang/dartdoc/blob/master/lib/src/model.dart#L1568), but the override in Field inspects the element directly to make that determination. Now looking for the right place to adjust things so isFinal == False when there is a getter.

[jcollins-g]

New version handles the case of read-only getters without adding "final" to them. I've dropped adding deprecated as text unless the user specified @Deprecated('with something here'), since that seems duplicitous with the cross-out. Same with const/static being duplicitous since they are listed in their own sections indicating they are const/static.

Here are a couple more screenshots; will work on getting this into a pull request shortly.

[devoncarew]

Screen-shot looks great!

If doing a whitelist, you'll probably want that list to contain the annotations from the meta package: https://www.dartdocs.org/documentation/meta/1.0.4/meta/meta-library.html.

[keertip]

Looks good Janice!