From: Richard E Maine on
Paul Van Delst <Paul.vanDelst(a)noaa.gov> wrote:

> Richard E Maine wrote:
> > I personally think that the terminology is unfortunate in that public
> > indeed means public, but private doesn't really mean private. Instead,
> > private means something closer to "don't export from here".

> But, despite this subtlety, isn't the end result what people would
> commonly (intuitively?) expect?

No. Not even close. If it were, then there wouldn't have been multiple
interpretation question about it, compilers that got it wrong (but were
fixed after the interps), and users that still misinterpret it. It took
a good year to settle on the crucial interp answer. That was a year of
actual debate - not including the bureaucratic bits of formalizing the
answer.

> Public means that entities are "visible from" a module if that module is
> PUSEd. rivate means that entities are NOT "visible from" a module if that
> Pmodule is USEd.

You missed the bit about there being restrictions in the standard. Those
restrictions are *NOT* intuitive - not even close. (They were also
misguided in the first place, and are finally all gone in f2003, but
that's another matter). That's where all the fuss is.

Let's see an example of one of those nasty restrictions. How about the
10'th constraint in 5.1 of f95 (if I counted right - it's at page:line
[48:15].
"An entity shall not have the public attribute if its type has the
private attribute."

Apply that to

module m2
use m1
private
private my_type !-- Unnecessary, but just to make it extra clear.
type (my_type), public :: x
end module m2

where my_type came from m1. In this module, x is public, and my_type
is....

If the answer and all of its implications to that constraint are obvious
and intuitive to you, then we need you on the committee because you are
really, really good. :-)

The answer is that the constraint does not apply because my_type isn't
private. It is just "not a public entity of the module", which isn't the
same thing. The exact argument and supporting material are subtle; I'm
not going to repeat them here.

Note that this is a very common style. If you couldn't do this, things
would get "bad". And there are other related ones. If this counted as
my_type being private, then by the time you were done chasing all the
implications, you pretty much would be forced to always make everything
public in lots of large apps. That wouldn't have been good.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
From: James Giles on
The argument that people don't use ONLY because it's
too much trouble sound almost identical to the complaints
about IMPLICIT NONE. I still think everything visible
in a given scope should be declared there. For module
entities, all you have to declare is where they came from.
The ONLY clause declares the entities, and the corresponding
USE says where thay came from. That's hardly much of
a hardship.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


From: Rich Townsend on
James Giles wrote:
> The argument that people don't use ONLY because it's
> too much trouble sound almost identical to the complaints
> about IMPLICIT NONE. I still think everything visible
> in a given scope should be declared there. For module
> entities, all you have to declare is where they came from.
> The ONLY clause declares the entities, and the corresponding
> USE says where thay came from. That's hardly much of
> a hardship.
>

As an alternative, I make sure that in each module all of the public entities
have the same prefix, which is unique across differing modules.

Hence, I can always tell exactly where every routine, parameter, etc comes
from --- and by looking at the actual code where these things are used, rather
than having to look back at the ONLY clause.

cheers,

Rich
From: Richard Edgar on
James Giles wrote:
> The argument that people don't use ONLY because it's
> too much trouble sound almost identical to the complaints
> about IMPLICIT NONE. I still think everything visible
> in a given scope should be declared there. For module
> entities, all you have to declare is where they came from.
> The ONLY clause declares the entities, and the corresponding
> USE says where thay came from. That's hardly much of
> a hardship.

Just don't forget about removing things from the ONLY list when you
delete the _last_ reference to them in the current scoping unit.

I would also add that in one code I'm currently using, a USE statement
with ONLY tends to end up looking like

USE MyModule, ONLY : MyModSubA, MyModSubB, MyModSubC, etc.

I wouldn't say that ONLY should never be used, but the more I think
about it, the more of a hassle it seems to be in a good number of cases.

Richard
From: James Giles on
Rich Townsend wrote:
> James Giles wrote:
>> The argument that people don't use ONLY because it's
>> too much trouble sound almost identical to the complaints
>> about IMPLICIT NONE. I still think everything visible
>> in a given scope should be declared there. For module
>> entities, all you have to declare is where they came from.
>> The ONLY clause declares the entities, and the corresponding
>> USE says where thay came from. That's hardly much of
>> a hardship.
>
> As an alternative, I make sure that in each module all of the public
> entities have the same prefix, which is unique across differing
> modules.
>
> Hence, I can always tell exactly where every routine, parameter,
> etc comes from --- and by looking at the actual code where these
> things are used, rather than having to look back at the ONLY clause.

I almost wrote a second paragraph in the above denouncing
that very practice. That means that all the entities from
modules have very verbose names (which I usually have
to rename anyway if I plan to use them several times - just
to avoid that problem). If legibility is important, using
novels as identifiers is counterproductive. Not to mention
overloaded operators - just a few days ago I posted an
overloaded concatenate operator. How do you propose
to name it so that you can tell what module it's from?

And, during code development, the proper packaging changes
from time to time. If I move an entity from one module to another,
but I'm using ONLY clauses, I merely have to change the module
name on the USE statement. If I have these verbose names that
contain the module name within them, I have to change every use
throughout the code. And, what of submodules? Do the names
of the entities have the parent's module name as part of their
own names? Or the submodule's name? Both?

Finally, if using an ONLY clause is a hardship, isn't writing
all those long names throughout the code even more of a hardship?

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare