Use enhanced enums

[JosefWN]

When Dart 2.17 is released, enhanced enums will simplify our code a bit: dart-lang/sdk#47849

Examples:

• Block option SZX could be an int enum
• CoapCode could be broken down into int enums
• CoapMediaType could be int enum
• CoapMessageType could be int enum
• Request.observe could be int enum?
• CoapDefinedAddress could be string enum?

[JKRhb]

Dart 2.17 has just been released by the way :) https://medium.com/dartlang/dart-2-17-b216bfc80c5d

[shamblett]

Yes, got it, FFI updates and experimental RISCV support are good news for me with my IOT hat on.

[JKRhb]

I just noticed that the option type numbers might also be an interesting place where the enhanced enums could be used. I'll try to come up with a PR for that soon.

[JKRhb]

I started working on refactoring the CoapCodes using enhanced enums by the way :)

[JosefWN]

A couple of minor things I noticed, which will likely resolve themselves with the re-write, but mentioning just in case. Not all codes are represented in codeToString (at least continues is missing), and the fallback doesn't show the code:

    if (isValid(code)) {
      if (isRequest(code)) {
        return 'Unknown Request [code {0}]'; // `$code` rather than `{0}`?
      // ...

Somewhat related: I suppose toString in CoapMessage could also use a typeString getter (like codeString) for type. Then we would get: Type: NON rather than Type: 1 in the printouts.

[JKRhb]

• Block option SZX could be an int enum
• CoapCode could be broken down into int enums
• CoapMediaType could be int enum
• CoapMessageType could be int enum
• Request.observe could be int enum?
• CoapDefinedAddress could be string enum?

I think from this list, we could mark CoapCode, CoapMediaType, and CoapMessageType as resolved now :) Should we maybe turn this issue into a task list for tracking the remaining candidates for enhanced enums?

[JosefWN]

Done! :)

[shamblett]

Package re released at version 5.0.0.

[JKRhb]

Thank you for releasing the new version, @shamblett! I think we could reopen this issue, though, as there are still a couple of places where enhanced enums could be used (see the task list above).

[shamblett]

Yes no.problem a bit overly aggressive with my tidy up.

[JKRhb]

Block option SZX could be an int enum

This is now also addressed by #122 and can be checked once the PR has been merged :)

[JKRhb]

I think with #136 and #122 we have covered all checkboxes in @JosefWN's initial comment :) Do you see any more potential for refactoring with enhanced enums?

[JosefWN]

LGTM!