Switch to using enhanced enums for the log levels

[VictorUvarov]

When switching over LogRecord.Level i get an error (maybe a lint error) saying

The switch case expression type 'Level' can't override the == operator.dart(case_expression_type_implements_equals)

Example:

Logger.root.onRecord.listen((LogRecord record) {
    var m =
        '${record.loggerName} ${record.level.name}: ${record.time}: ${record.message}';
    var log = _getLogger();

    switch (record.level) { // ERROR here
      case Level.SEVERE:
        log.wtf(m);
        break;
      case Level.SHOUT:
        log.e(m);
        break;
      case Level.WARNING:
        log.w(m);
        break;
      case Level.INFO:
        log.i(m);
        break;
      case Level.CONFIG:
      case Level.FINE:
        log.d(m);
        break;
      case Level.FINER:
      case Level.FINEST:
      default:
        log.v(m);
    }
  });

If i force run the application and ignore the error, it runs fine.

Context:

I am using pedantic as my linter

[shilangyu]

This can now be solved by using enhanced enums, but it would mean the SDK constraint has to be bumped up to dart 2.17. Would that be a wanted change? Tagging the last person to send a commit to this repo: @devoncarew

[devoncarew]

I'm not sure how compatible the change would be from defining levels as a psuedo-enum class to using actual enums (i.e., would existing clients see errors)? I agree the change would be nice - it would help to modernize this package.

I'll tag this with next-breaking-release so we don't lose track of the idea.

[shilangyu]

From what I can tell this change would be breaking in the following sense:

• If someone was extending Level (why?) it will no longer work
• If someone was constructing custom levels it will no longer be possible (was it ever the intention for Level to have a public constructor and not be sealed though? It exposes static const LEVELS which would indicate that it is an exhaustive list of possibilities)

Also, it would be probably nice to rename all these variants to be camelCase instead of SCREAMING_CASE since it is not the style of Dart.

What do you think? Would you welcome a PR with these changes? I could prepare something.

[devoncarew]

What do you think? Would you welcome a PR with these changes? I could prepare something.

We've held off on the screaming caps change just because this package is so widely used and the cost / benefit to the disruption just wasn't there.

I think the change to using enhanced enums is similar. At some point we will decide to revise the API in breaking ways, but for not I would hold off on any PR. Thanks!