Swietanowski Artur writes:
> > More interesting examples are things like public types with private
> > components. For such things, we need to know the private part when
> > writing the public interface.
>
> I agree that lack of such capability (public types with private
> components) is a problem with F90. I'm not sure what you mean by
> the second quoted sentence. Could you, please, clarify?
Ok. See below.
> > And in f2k, it will probably (as in
> > its on the "to do if time" list, and its *REALLY* easy to do; about
> > 3 sentences in the standard, if I recall) be allowed to have private
> > types for public variables and dummy arguments of public procedures.
>
> In my view this is very much needed if meaningful access protection
> to derived type components is to be obtained. The obvious way
> of obtaining perfect protection is to declare the whole type
> private and access it only through 'entitled' procedures.
That sounds like public types with private components (which we have
now). Nothing except for "entitled" procedures (currently meaning
those in the defining module) can know anything about the components.
When you have a truly private type, you can't do *ANYTHING* with the
type outside of the declaring module. You don't, for example, have
access to the type name at all. Thus you can't even declare a
variable of the type in the first place (much less mess with its
components). The current f90 and f95 standards say that if you have
such a type, then a variable of that type cannot be public, and a
public procedure can't have a dummy argument of such a type. It has
been proposed to lift these restrictions.
If you allow a public object of private type, then the things that you
can do to it are naturally limited, but there is no need to add extra,
artificial limits on top of those inherent in the thing.
There are a few cases where lifting the restriction might allow a few
things that are actually useful.
A case I've run into is having a public subroutine with an optional
argument of private type. Currently that's not allowed, but why not.
It is easy to imagine (and I have had) cases where it is meaningful.
The optional argument is essentially unuseable on calls from outside
of the module (with exceptions noted below) because you can never
declare an object of that type outside of the module. But that
restriction comes "naturally" without requiring special rules. Calls
from within the module might still use the optional argument.
Example
module my_mod
private
type my_type
integer :: a_component
!---- etc.
end type
public my_sub !-- This is illegal in f90/f95
contains
subroutine my_sub(arg)
type(my_type), optional :: arg
.....
end subroutine my_sub
subroutine some_other_module_sub
type(my_type) :: x
call my_sub(x) !---- No problem with this call.
end subroutine some_other_module_sub
end module my_mod
program main
use my_mod
call my_sub !-- No inherent reason why this call shouldn't be ok
end program main
Another case of possible use is where you actually don't want
"outside" procedures to be able to declare objects of the type. The
module declares all of them that are allowed to exist, and outside
procedures can only use the ones declared in the module. (Perhaps
relevant when the module is managing something that there inherently
cxan be only one of - like an i/o device, with the derived type
containing stuff needed in managing it.
To repeat what I said before, the main reason for lifting them is that
they achieve nothing and are very subtle to correctly interpret and
implement, not that there is a great demand for the capability.
The above examples are just to illustrate what is being talked about,
not to argue that these are greatly needed features (though there is
at least some use).
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|