Small question concerning use

Small question concerning use

[Eric Merritt]

Hello everyone,

I am fairly new to Ada, though I already love the language, and I have
a small question concerning the 'use' keyword. Many books and quite a
few postings to this group say not to use it at all, even the style
guide is fairly adamant about avoiding it. Yet, in many packages I see
it used frequently. Is there a set standard for when to use it and
when not to use it? I would just as soon not use it at all except some
packages names get really (really) long. Ok, lets say you don't use
it, is it then acceptable to use 'rename ' to shorten long package
names. Which is the more acceptable?

Thank you for your time,
Eric

Rename is much better.

[Petter Fryklund]

That way you can always see in which file to look for an entity (possibly
indirectly, but still). I use it frequently, ie
package ACL renames Ada.Characters.Latin-1;

Re: Small question concerning use

[Marc A. Criley]

Eric Merritt wrote:
> 
> Hello everyone,
> 
> I am fairly new to Ada, though I already love the language, and I have
> a small question concerning the 'use' keyword. Many books and quite a
> few postings to this group say not to use it at all, even the style
> guide is fairly adamant about avoiding it. Yet, in many packages I see
> it used frequently. Is there a set standard for when to use it and
> when not to use it? I would just as soon not use it at all except some
> packages names get really (really) long. Ok, lets say you don't use
> it, is it then acceptable to use 'rename ' to shorten long package
> names. Which is the more acceptable?

Well, unfortunately discussing the appropriate use of "use" never
results in a "small" discussion :-)  Look back at previous discussion
threads on this topic in this newsgroup and you'll see what I mean.

"Use" is probably more commonly seen in books and postings because it
makes for less cluttered listings of (and this is the key justification)
_SHORT_ sections of code.  In production code you're more interested in
clarity of expression to the reader, so "use" tends to be discouraged.

There seems to be four general approaches, advocates of each of which
have posted in this newsgroup in the past:

1) Use "use" freely and rely on your code browser to look up a reference
when you need it.

2) Use "use" only for "utility" packages, like IO, strings, math
packages, and data structures.

3) Do not use "use", and use "renames" to shorten selected notation
references that start getting really long.

4) Do not use "use", and do not use "renames".  Choose package and
entity names very carefully so that they compose well.

And then there's "use type" to get direct visibility to a type's infix
operators.  Some consider it a godsend, others think it vile.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Small question concerning use

[Ted Dennison]

In article <19130ae.0110151428.65937d5b@posting.google.com>, Eric Merritt
says...
>I am fairly new to Ada, though I already love the language, and I have
>a small question concerning the 'use' keyword. Many books and quite a
>few postings to this group say not to use it at all, even the style
>guide is fairly adamant about avoiding it. Yet, in many packages I see
>it used frequently. Is there a set standard for when to use it and
>when not to use it? I would just as soon not use it at all except some
>packages names get really (really) long. Ok, lets say you don't use

That is a *very* contraversial issue here. My advice is to do without it if you
are new to Ada, because if nothing else it forces you to pay attention to where
everything is comming from. Once you are much more proficient you will be
capable of making an intelligent decision on when/if it is OK to use.

>it, is it then acceptable to use 'rename ' to shorten long package
>names. Which is the more acceptable?

On that I'd say "no". Its not so bad on projects where there is a standard
agreed-upon documented set of "abbreviations". But it is sheer hell trying to
read code where someone renamed all sorts of stuff.

I'd say you should stick with full dot notation until you get your feet fully
under you. After you get used to it, you may find that things like
Ada.Strings.Unbounded.To_Unbounded_String aren't really all that bad.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Small question concerning use

[Darren New]

Ted Dennison wrote:
> I'd say you should stick with full dot notation until you get your feet fully
> under you. After you get used to it, you may find that things like
> Ada.Strings.Unbounded.To_Unbounded_String aren't really all that bad.

I'd be bothered by such stuff less if it wasn't so repetitive. 
Ada.Streams.Stream_Element_Count instead of Ada.Streams.Count?
How many times do I have to say "Unbounded" or "String"?
The problem comes when there's a 6-line expression like
i : Ada.Strings.Unbounded.Unbounded_String :=
  Ada.Strings.Unbounded.To_Unbounded_String(J)
   Ada.String.Unbounded."&"
  Ada.Strings.Unbounded.To_Unbounded_String(K);

I don't see that as at all readable. I'm not sure quite what would be
better, tho. I'm just a newbie. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: Small question concerning use

[Ted Dennison]

In article <3BCC8AF0.A8B1115D@san.rr.com>, Darren New says...
>
>Ted Dennison wrote:
>> I'd say you should stick with full dot notation until you get your feet fully
>> under you. After you get used to it, you may find that things like
>> Ada.Strings.Unbounded.To_Unbounded_String aren't really all that bad.
>
>I'd be bothered by such stuff less if it wasn't so repetitive. 
>Ada.Streams.Stream_Element_Count instead of Ada.Streams.Count?
>How many times do I have to say "Unbounded" or "String"?

Well, yes. You aren't missing anything, your observation is dead on.
Unfortunately the folks who wrote the Ada libraries "took sides" on this issue.
The best thing to do here is to take it as a constant reminder to yourself to
pick better names for your *own* packages and objects.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Small question concerning use

[David Starner]

On Tue, 16 Oct 2001 20:26:16 GMT, Ted Dennison <dennison@telepath.com> wrote:
>>I'd be bothered by such stuff less if it wasn't so repetitive. 
>>Ada.Streams.Stream_Element_Count instead of Ada.Streams.Count?
>>How many times do I have to say "Unbounded" or "String"?
> 
> Well, yes. You aren't missing anything, your observation is dead on.
> Unfortunately the folks who wrote the Ada libraries "took sides" on this issue.
> The best thing to do here is to take it as a constant reminder to yourself to
> pick better names for your *own* packages and objects.

The problem is, how? Ada.Streams.Count is un"use"able; it would conflict
with other variables named Count (besides being just a bad name all
around). How do you name a variable so it doesn't conflict with other
names when "use"d, but doesn't do too much repetition. What should
Ada.Streams.Stream_Element_Count have been named? (Count's just an awful
name, anyway, even outside a "use" enviroment; a count of what?)

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: Small question concerning use

[tmoran]

> How do you name a variable so it doesn't conflict with other
> names when "use"d, but doesn't do too much repetition. What should
> Ada.Streams.Stream_Element_Count have been named? (Count's just an awful
> name, anyway, even outside a "use" enviroment; a count of what?)
  Sometimes you just have to decide at design time whether the package
is going to be "use"d or not.  If not, then
  package Apples
    Count : Integer;
lets you say
  Apples.Count :=
but, as you say,
  use Apples;
  ...
  Count :=
would be confusing.
OTOH, Ada.Streams.Stream_Element_Count was clearly designed with the
intention of "use Ada.Streams", in which case Stream_Element_Count
is very readable, while Ada.Streams.Stream_Element_Count is ugly.

Re: Small question concerning use

[Darren New]

tmoran@acm.org wrote:
> OTOH, Ada.Streams.Stream_Element_Count was clearly designed with the
> intention of "use Ada.Streams", in which case Stream_Element_Count
> is very readable, while Ada.Streams.Stream_Element_Count is ugly.

Right. My thought was that "always avoid use - it leads to ambiguities"
is too sweeping a statement in the face of this sort of naming
convention.

Hmm... The hardest part of Ada for me seems to be naming conventions, at
least so far. Is this good or bad? :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: Small question concerning use

[Larry Kilgallen]

In article <3BCCF185.A4512DDA@san.rr.com>, Darren New <dnew@san.rr.com> writes:
> tmoran@acm.org wrote:
>> OTOH, Ada.Streams.Stream_Element_Count was clearly designed with the
>> intention of "use Ada.Streams", in which case Stream_Element_Count
>> is very readable, while Ada.Streams.Stream_Element_Count is ugly.
> 
> Right. My thought was that "always avoid use - it leads to ambiguities"
> is too sweeping a statement in the face of this sort of naming
> convention.

That is why not everybody supports that statement.

Re: Small question concerning use

[Ted Dennison]

In article <3BCCF185.A4512DDA@san.rr.com>, Darren New says...
>
>tmoran@acm.org wrote:
>> OTOH, Ada.Streams.Stream_Element_Count was clearly designed with the
>> intention of "use Ada.Streams", in which case Stream_Element_Count
>> is very readable, while Ada.Streams.Stream_Element_Count is ugly.
>
>Right. My thought was that "always avoid use - it leads to ambiguities"
>is too sweeping a statement in the face of this sort of naming
>convention.

That's backward thinking, in my book. Just because someone made an awkward
naming choice on some packages is no reason to abandon the Right Thing.

Now if you don't feel that avioding "use"s is the Right Thing for other good
reasons, then that's fine. But horrible choices made by the library designers
are not a good reason.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Small question concerning use

[Ted Dennison]

In article <9qi8ls$a2g1@news.cis.okstate.edu>, David Starner says...
>
>On Tue, 16 Oct 2001 20:26:16 GMT, Ted Dennison <dennison@telepath.com> wrote:
>> The best thing to do here is to take it as a constant reminder to yourself to
>> pick better names for your *own* packages and objects.
>
>The problem is, how? Ada.Streams.Count is un"use"able; it would conflict
>with other variables named Count (besides being just a bad name all

First off, it probably wouldn't be "Count", but rather "Element_Count" (we are
just talking about removing the redundant information here). 

Secondly, it is quite usable. The only problem is that, in the event of a clash,
you can't get at it when its enclosing package has been used, as the multiple
definitions hide each other. In this case, that's fine, as you can just specify
enough extra information to disambiguate it in this case. Your use still works
fine for all the other stuff in that package.

So in the event of a name clash, this would read "Streams.Element_Count" in a
"use"er's code, which differs from the current version a "use" user has to type
by all of two characters. One of those characters is a "." instead of a "_". The
"." version gives the reader more information about the object, so its clearly
the better version.

I think we should all be able to agree that its just plain silly to try to fight
against "use"ers removing package information from their code (which is exactly
what someone *wants* to do when they use a "use" clause) by manually duplicating
that package information in the name of every entity in the package.

>around). How do you name a variable so it doesn't conflict with other
>names when "use"d, but doesn't do too much repetition. What should

You can't, of course. That's one of the dangers you run every time you perform a
"use". You rolls your dice, you takes your chances. Its not a fatal problem. If
you were willing to type that disambiguating information when it was part of the
object's name, what's the problem with typing it when it is its enclosing
package's real name? It's just a "." vs. an "_".


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Small question concerning use

[Ted Dennison]

In article <3BCC8AF0.A8B1115D@san.rr.com>, Darren New says...
>
>  Ada.Strings.Unbounded.To_Unbounded_String(J)
>   Ada.String.Unbounded."&"
>  Ada.Strings.Unbounded.To_Unbounded_String(K);
>
>I don't see that as at all readable. I'm not sure quite what would be
>better, tho. I'm just a newbie. :-)

Ahhh. Well, I *do* think "use type" is perfectly fine, even for newbies. (Are
there folks who don't? I keep hearing that there are.) So I'd expect this code
to look more like:

Ada.Strings.Unbounded.To_Unbounded_String (J) & K; 
-- The second conversion was unnessecary, as there are "&"
-- functions that take String as one of the parameters.

That looks quite a bit better, and its still clear from reading this exactly
what type will result and where I can go to look it up. Sure, it would have been
nice if you didn't have to type "Unbounded" and "String" twice, but most
*decent* package designers won't do that to you. ;-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Small question concerning use

[Marin David Condic]

This discussion shows up here quite often. Perhaps something should be in
the FAQ?

There is no overall concensus on the issue of "use" clauses. You will find
advantages and disadvantages on either side of the issue. Generally, there
is some concensus that they should be avoided until such time as it starts
to make what you are doing more clear to have the use clause. Start with no
use clause. If you find that you are doing silly things like "X :=
Some_Package."<=" (A, B);" then back off a little and try the "use type" to
make the operations visible. If your code is getting really cluttered with
Long.Confusing.Dotted.Names then you might back off some more. Try to
restrict the use clause to just the scope that needs it to make things more
clear.

OTOH, if you have a use clause for every package you "with" you are really
no worse off than you would be in most other languages and you can always
disambiguate whatever you need to with the dotted notation. Code clarity?
Many modern Ada-oriented editors will help you locate the exact definition
of a thing if/when you get confused - unless the code doesn't yet compile!
:-)

As you develop more code in Ada, you will probably develop a sense of where
to draw the line such that it works well for you. If you're on a joint
project with others, establish & follow some project guidelines on this so
that you are at least consistent.

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/


"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:19130ae.0110151428.65937d5b@posting.google.com...
> Hello everyone,
>
> I am fairly new to Ada, though I already love the language, and I have
> a small question concerning the 'use' keyword. Many books and quite a
> few postings to this group say not to use it at all, even the style
> guide is fairly adamant about avoiding it. Yet, in many packages I see
> it used frequently. Is there a set standard for when to use it and
> when not to use it? I would just as soon not use it at all except some
> packages names get really (really) long. Ok, lets say you don't use
> it, is it then acceptable to use 'rename ' to shorten long package
> names. Which is the more acceptable?
>
> Thank you for your time,
> Eric

Re: Small question concerning use

[Dr. Michael Paus]

I wonder why in these discussions about the use of "use" people
always use more or less trivial examples. I think for these
examples the issue is more or less a matter of taste. The real
problem with "use" arrises if you make intensive use of object
oriented features in Ada. E.g. if you have a package "My_Pack_A"
in which you define a tagged type "My_Class_A" and another
package "My_Pack_B" in which you define a tagged type "My_Class_B"
which is derived from "My_Class_A". Now assume that B inherits
a method "My_Method" from A. If you now have an instance
of the B class and you want to call one of its methods, say

   B : My_Pack_B.My_Class_B;
   xxx.My_Method(B, Some_Value);

So what is the right package name to put in for xxx? When you
have found out you certainly admit that this may be quite
cunfusing although there is of course a clear logic behind it.

My experience is that if you intensively use object oriented
features the use of "use" quickly becomes a pain in the ...:-)
And if you are interested I can give you examples where in this
particular case the use of "use" resulted in severe bugs in the
code which were very hard to track down. Also the use of "use type"
does not help here because it only makes the operators of a type but
not the primitive methods of a class type visible.

Michael