On Tue, Jun 30, 2015 at 10:00:11AM -0400, Phil Shafer wrote:
> Juergen Schoenwaelder writes:
> >I am not afraid of nonsense in data models since nonsense will not be
> >implemented. I would leave it to compiler writers to warn about
> >nonsense constructions a compiler can detect without requiring a
> >statement in the language definition trying to prohibit nonsense.
> >There are many ways to define degenerated lists in YANG; ruling out
> >one of them does not help that much and it creates inconsistencies -
> >why is one way to define a degenerated list forbidden but the others
> >are legal?
>
> This really isn't the way standards work, right? "gcc" can warn when
> I do something like "int foo(){ return 0; return 1;}" but it can't
> decide that it's invalid or refuse to generate a .o file for it.
> I can choose to tighten gcc's restrictions with -W flags, but when
> code compiles under gcc and doesn't under clang, when one or the
> other isn't implementing the C standard.
I don't get it. I do not think the C standard says the example above
is invalid C. It is perhaps pointless C or likely a coding error but
as long as the semantics are clear, things are well defined.
> Past that, allowing pointless constructs like this allows users
> to make mistakes that might not be warned by their tool chain,
> and the earlier an error is caught, the lower it's cost.
>
> Worse, allowing pointless constructs like this means that the
> probability of some nitwit using it quickly approaches 1, at
> which point tool chains that barf on it will need to start
> supporting it.
You can achieve the same pointless construct in many other ways.
Trying to enumerate all of them is tricky and it is very easy to make
mistakes.
> I'm not asking us to make pointless constructs like "leaf foo {must foo==0;}"
> but empty keys it truly pointless. Making it illegal is a benefit
> to the enitre YANG world and not doing so it a pointless expense.
I guess it is subjective where to draw the line. Disallowing empty in
a key but at the same time allowing the example Martin presented shows
that the line is really somewhat arbitrary.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
