Types, packages & objects : the good old naming conventions question (without religious ware)
in [ADA]
|
Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings
From: Stephen Leake on 10 Nov 2009 02:58 "Vincent Marciante" <vmarciante(a)decilog.com> writes: >>> Supposedly, then, they did not deem String : String a natural thing, >>> even though they were good programmers. >> >> That's a stretch! Avoiding actual ambiguities is a better reason. But >> I don't presume to read their minds. It would be interesting to read >> some rationale on this; I don't think there is any in the Ada Language >> Manual. > > What I gathered was that the original chief language > designer constructed the language rules with a goal > of trying to drive/impose the necessity of "good" > program architecture and trying to prevent/discourage > "bad" program architecture and I think that the following > was one of the things that was to be promoted: > > - separating (having in different packages) the declaration > of types (abstract data types) and object of the type. Maybe, but we are also talking about subprogram parameters, which are in the same package. And there are certainly valid use cases for local types, especially subtypes. > I think that having two namespaces would have made > having both in the same declarative region easier Not much, it just would have avoided _Type. > but that would only really come up for the type > and only one object (or as a yucky "workaround") > an array of them) declared together. Clearly, whenever > there are two objects of the type, the simple name > of one of them _must_ be different than the name of > the type unless they are in different declarative > regions. Again, not true for subprogram parameters; there are many (one per subprogram) with the same name. I guess the subprogram parameter list can be thought of as a separate declarative region; I'm not sure it is formally. > Also, I showed that the "parameter of subprogram > declaration" case (which was the old example that > I brought up in an earlier message) is easily and > elegantly dealt with by the sjkdf.type_name construct Yes. > So, that there is really no need for two namespaces but there also > is really is no need for any overall naming convention either! No, there is still a need for a convention; people need to know how to react to the compiler error message. You are proposing that the convention be "add enough of the full name of the type to disambiguate". Which is also the convention for resolving other name ambiguities (rather than changing one). -- -- Stephe
From: Vincent Marciante on 10 Nov 2009 11:53
"Stephen Leake" <stephen_leake(a)stephe-leake.org> wrote in message news:uaayu24yf.fsf(a)stephe-leake.org... > "Vincent Marciante" <vmarciante(a)decilog.com> writes: > >>>>> That's the first time I've seen that suggestion. >>>> >>>> Or maybe you forgot! >>> >>> Always possible. >>> >>>> The following is part of a old discusion to which you contributed: >>> >>> <snip> >>> >>> I don't see your point; that old discussion does _not_ propose using >>> <package>.<type> to resolve the ambiguity. >> >> My point was to show that my mentioning using >> <package>.<type> to resolve ambiguity nicely >> in my first message was actually not the first >> time that it was mentioned (ever if not explicitely) >> in c.l.a. > > I still don't get it. If it was not mentioned explicitly, how was it > mentioned? If I had seen that suggestion before, I might be using it > now. >> No big deal, as long as there may now be at least >> one less "_Type" writer. ;) > > Not likely, after 15 years of habit forming. I just reread all of the old thread and see exactly what was previously discussed. How about lets just leave it at this: Ada _does_ allow one to name an object with the same simple name as that of its type as long as the type is in a different declarative region. Also, (obviously only) one subprogram parameter can also share the same simple name as its type as long as the type name is fully qualified. Given that, adding noise characters to a type name or a object name is not scrictly necessary. Vinny |