Re: [YANG] so many naming scopes

["tom.petch" <[e-mail]>]

----- Original Message -----
From: "Bert Wijnen - IETF" <[e-mail]>
To: "Andy Bierman" <[e-mail]>om>; "Balazs Lengyel"
<[e-mail]>
Cc: <[e-mail]>
Sent: Friday, January 04, 2008 1:08 PM
Subject: 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.
>

Agree absolutely, but, sadly, developers may not be either good or smart or
both.  And your definition of smart may not be mine, it may be someone who is so
clever that they come up with something that is incomprehensible to the mere
mortals who inherit what they have produced.

A goodly part of my coding has been maintenance, having to reverse engineer the
existing language before being able to change it; the best developers produce
something that is so simple, so obvious that everything thinks 'I could have
done that' - except that they couldn't.  The worst developers - who are often
very clever - produce something that needs a Ph D in Philosophy to unravel.

There are languages where no word is reserved, where the same symbol(word) can
be used for label, type, module etc.  XML is arguable worse with the ability to
start a fresh namespace on alternate lines.  These belong in the bin.

So, I think that having restraints is a good thing, for the benefit of the good
and smart maintainers who have to put up with the output of diabolical
developers.  The number of discrete naming scopes that can appear in a 200-line
module should be severely restricted.

Tom Petch


> 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
> > >> [e-mail]
> > >> https://www1.ietf.org/mailman/listinfo/yang
> > >
> >
> >
> >
> > _______________________________________________
> > YANG mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/yang
> >
>
>
>
> _______________________________________________
> YANG mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/yang



_______________________________________________
YANG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/yang