Re: Ada95 tutorials with sample code.

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Just an observation on a subject that has been beaten to death and run over
so many times that it is a greasy spot in the middle of the highway..... :-)

Many other languages give you a means of pulling in identifiers from other
"packages". Most older languages didn't give you any means of distinguishing
between an identifier from one context and one from another. Some newer
languages are providing things similar to Ada's context clauses so that
identifiers can be distinguished. (I'm particularly thinking of C++'s
namespaces and how you can now go SomeContext::SomeIdentifer) Its a great
feature to help sort out the numerous identifiers that exist in large
projects. We didn't always have it and we found ways of dealing with it in
older environments, so maybe some of those techniques apply here. At least
we can say that we have more options now than we did in other languages.

Ada's context features seem to me to be better than others I've seen because
they are very clear and unambiguous. (C++, for example, gets stuck having to
support most of the bad habbits that are exhibited in old C code) It is an
inherent part of the language that things exist within a context and they
have fully qualified names that let you find them.

The "use" clause can make things more or less readable, depending probably
more on the natural communicative gifts of the programmer writing the code.
Fortunately, modern development environments can provide considerable help
in finding an identifier if it wasn't fully qualified, so you kind of have
multiple options with plusses and minuses on all sides. There seem to be
three popular categories:

1) Never(with-possible-exceptions) use "use" so that you have fully
qualified names everywhere.

2) Use the "use" clause freely(with-possible-exceptions) so that
all(most/some) names appear to be what they are & rely on tools to help you
find them if you need to.

3) Use various renaming techniques to avoid the "use" clause yet provide
"short-form" qualified names so you get some of the best features of (1) and
(2) and avoid some of their pitfalls.

Since it seems to me that there are advantages and disadvantages for any of
these choices, its a sort of "Engineering Decision" with no clear "Right"
answer. Maybe the best thing to do is what projects ought to do about other
style issues (Capitalization, Indentation, Named-vs-Positional parameter
association, etc.....) Declare something to be the "Approved" approach and
be consistent in its usage. At least that way, programmers looking at the
code are going to know what to expect. I'm a big proponent of consistency
because I think it works well for speeding development and maintenance work.

Just my $0.02.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Sven Nilsson" <emwsvni@emw.ericsson.se> wrote in message
news:3AA5E92D.8446E7AB@emw.ericsson.se...
> Howdy
>
> I'm replying to my own entry here to try and recap some of the things
> thats been said. No flaming at all as far as I can see, thank you very
> much people!
>
> Most people seem to agree that the use-clause can be a dangerous thing,
> but there are voices raised in it's defence:
>
> 1. If you write/design your code properly, the use-clause won't be a
> problem and will make the program easier to read and maintain.
> 2. Standard things like Text_Io and Strings should be known to most
> Ada-users and in that case a use-clause can be used safely.
> 3. Using full names means the code will be less readable (this is noted
> in the paper "In defence of the use clause" available at
> http://www.adalog.fr/publica2.htm and is consistent with what I know of
> readablility index and such things (I'm a teacher at heart))
>
> All of these are good solid reasons to use "use", but I do not agree
> with them.
> The first one would be nice if it worked, but in my experience people
> don't think before they do. As I said in my last post, I work in big
> projects with a lot of people working on the same code in different
> teams, trusting that everyone has the same view of what is proper design
> is bordering on stupidity. "Trust is good, control is better" as the old
> saying goes.
> The second one should be very true indeed. My example in the other post
> (with TIO) is pretty stupid, really. BUT clever chaps tend to override
> standard things like text_io and strings to add little extra features.
> Like Ted I'm often called in to  figure out why things don't work and
> I've actually had a case where a badly implemented debug-text_io was the
> whole problem...
> The third statement is probably the hardest to argue with. Having spent
> the last three years reading and writing Ada-code using full names, I've
> gown pretty used to "filtering" out the prefixes until I need them, but
> as a beginner the code always seemed horrible complicated. That's a
> problem...
>
> Other notes that I feel should be pointed out again is
>
> 4. The option of "use type", which I agree can be VERY usefull on
> occasion.
> 5. Using "use" in the procedures/functions where it is really needed.
>
> Number 5 is perhaps the way to go. If we can keep our methods (to use a
> java term) short (as in K.I.S.S), this could become very readable AND
> traceable. I'll have to look into that one further.
>
> The last point I'd like to recap is concerning renaming. Some people
> obviously consider this to be the worst thing to befall mankind and
> about two years ago I would have agreed. Now, however, we've been using
> rename for so long and so extensively that we actually have "renaming
> conventions". Almost every file you open have a number of renames at the
> top, renaming standard packages that we use extensively. These renames
> are ALWAYS the same, which means that it actually becomes quite
> readable. So why didn't we name the packages that way to start with, you
> might ask. Simple. I know what TEPC is, but you don't. It really is a
> package name of some 30 characters (yes, that long) which I don't want
> to type and certainly don't want to read everytime it's used, but TEPC
> is ok to read and it tells me what I need to know. If you don't know
> what TEPC is, you just look it up in the rename section of the package.
> This works, but I agree that it's not a perfect world...
>
> So much for the recap. Thank you for all the comments, I'll ponder over
> them as I look over our naming conventions and coding principles.
>
> -Sven