Re: [YANG] so many naming scopes

Bert Wijnen - IETF wrote:
>> 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.

<implementor-hat-on>
I don't mind your suggestion at all, since I already coded it
the way it's defined now.  It is not much more work to keep
typedefs, groupings, and objects (data/rpc/notification) separate.
</implementor-hat-on>

There is a sentence in sec. 6.2 about SHOULD not have names that are different
just in case.  There could be another sentence that says all identifiers
(of these 3 types) SHOULD be unique.  IMO, standard data models
do not need to overload these identifiers.  There are 63 chars,
instead of 32 in SMI, and (for data) it is only sibling nodes, not every node.

> 
> Bert

Andy

>>> 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