Re: [yang-doctors] guideline for enum and value?

["Einar Nilsen-Nygaard (einarnn)" <[e-mail]>]

On Feb 14, 2018, at 6:52 PM, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> wrote:

On Wed, Feb 14, 2018 at 06:41:52PM +0000, Einar Nilsen-Nygaard (einarnn) wrote:
Juergen,

The CBOR text does not invalidate the rationale I have discussed below. I recognize that the CBOR approach would break between model revisions if model authors arbitrarily reordered enums, but since that is already counter to RFC7950 backwards-compatibility guidelines, that is a non-issue.

So, even with the CBOR intent to use numeric wireline encoding, avoiding the explicit use of the value statement still seems like an overall benefit to the majority of developers.


Developers can shoot themself into the food in either way. So how are
we going to declare that one way of shooting yourself into the food it
better than the other?

Practical experience is one thing. I have had to deal very directly with this issue in embedded OS development in my day job, and I can say that had developers not used the value statement, things would have been easier. And so when it comes to the teams I work with, we have put this recommendation in place already, and that advice will not change irrespective of what this thread may, or may not, recommend.

And I'm fine with that! :-)

Here is my reasoning: If developers go and change explicit enum
values, I believe they more likely realize that they break a contract
by doing so. If they just change the order of enum definitions, they
may not realize that they also changed the value associated with an
enum. This is my reasoning.

You're making assumptions in this about the organizational structure and responsibilities of teams and the toolchains used that don't hold true everywhere when you say this, which is fine; it's also what I'm doing when I say that your reasoning above wouldn't have helped my scenario :-)

And yes, RFC 7950 section 11 first bullet clear says that regardless
how you shoot yourself into the food, it will hurt. So we can be
entirely silent about this because RFC 7950 section 11 really nails
it.

Fine, that works.

Cheers,

Einar