RE: [YANG] so many naming scopes

> Balazs Lengyel wrote:
> > While the use of many naming-scopes is understandable for the compiler
> > is it easy to understand for the reader ? IMHO no.
>
To which Andy responded:

> That is my concern as well.
>
> As in any engineering decision, we have to weigh the trade-offs.
> How much overall value is lost by forcing DM writers to
> maintain one set of identifiers (using up some of the 63 chars
> of minimum uniqueness), vs. the confusion of having the same
> identifier value mean many different things, even within the same file.
>

If the language can accept and easily handle it, then maybe we should
allow it to do so and not create CLRs.
A good and smart data-model-developer would/should still do the right
thing and make things as clear as possible for the user/reader of the
data-model. That means that one uses a style of definitions that is
obvious and clear and so would not cause confusion.

It is similar to using all sorts of short abbreviations/acronyms in names
of variables and such versus spelling out a longer name. The longer name
will make it much more readable/understandable for the new person who
read the module for the first time. That does not mean we must pre-scribe
that short-names/acronyms are not allowed.

>
> > I like Andy's proposal.

So I like the underlying reasons, but I am not sure we have to enforce it
in the langauge.

Bert
> > Balazs
>
> Andy
>
>
> >
> > Phil Shafer wrote:
> >> Andy Bierman writes:
> >>> Yes, of course one naming scope (the term namespace is taken)
> >>> amongst siblings, except nested typedef and grouping names
> >>> cannot mask similar definitions within an ancestor node,
> >>> or globally within the same module.  (This part already in the draft.)
> >>
> >> Isn't this dancing on the line of CLR?  Where's the logic of saying
> >> "don't do that" when there's really no ambiguity?  If I say "leaf foo
> >> { .. } typedef foo { .. }", my use of "type foo" is clear.
> >> Is there a situation where isn't not clear to the compiler
> >> what is meant?  Are we trying to get the compiler to enforce
> >> style rules when the language proper doesn't require them?
> >>
> >> Thanks,
> >>  Phil
> >>
> >>
> >> _______________________________________________
> >> YANG mailing list
> >> YANG@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/yang
> >
>
>
>
> _______________________________________________
> YANG mailing list
> YANG@ietf.org
> https://www1.ietf.org/mailman/listinfo/yang
>

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang