On Fri, 4 Sep 1998, Malcolm Cohen wrote:

> Hi Folks,
> 
> Hmm, looks like a couple of things should have been made clearer in
> 97-196r2 and 98-145r1.
> 
> Anyway:
> 
> You cannot make things disappear through type extension, because then
> it would no longer be an extension of the type.
> 
> Therefore any PUBLIC component in an extensible type is PUBLIC in all
> of its extensions.
> 
> Richard Maine said:
> > The situations I'm thinking
> > about, I'd be inheriting public components, but it would be the new
> > components I'd want to make private.
> 
> Absolutely, but there is more: a public parent component can always be
> accessed through a polymorphic variable (of the parent type) and therefore
> it is *impossible* to make such a component private in any effective manner.
> There is no point in providing an ineffective facility.
> 
> > Dr W.W. Schulz writes:
> >  > Also, one should only allow a PRIVATE component/procedure to become
> >  > PUBLIC but not vice versa for the same reasons.
> 
> This seems reasonable, provided (of course) that one has access to the said
> component in the first place.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  An inheriting type should have access to all components/procedures of the
  parent_type, so that shouldn't be a problem, or ...?

Maybe I haven't found all the necessary constraints and rules but I think
there is some clarification needed wrt a PRIVATE statement in extensible
types.
Let me just use a slightly different notation to highlight the point:

TYPE :: child_type                MODULE b
  INHERIT parent_type               USE a
  PRIVATE                           PRIVATE
  real :: x                         real :: x
  !etc.                             !etc
END TYPE child_type               END MODULE b

There has to be a different interpretation of the PRIVATE statement in
the extended type and the module. Polymorphism (NOT inheritance itself)
requires that the access-attributes of all components and procedures of
the inherited parent_type remain untouched by a PRIVATE statement in the
child_type whereas the PRIVATE in the module b also effects the access
of anything in module WHEN using module b.

I personally would ban any access statement in extensible TYPEs
and require that only access attributes can be used. This would make
everything very clear and uniform. No extra rules (except this ban)
would be needed:

TYPE :: new_type
  INHERIT old_type
  real, private :: x
  !etc.
END TYPE new_type

(Another reason but less stringent is the philosophy that one should
move away from attribute statements altogether and only use attributes
directly in the variable/procedure declaration. I see that USE has
acquired a possible attribute INTTRINSIC/NONINTRINSIC, it would be
nice to see PRIVATE/PUBLIC there as well, etc. as I suggested earlier.)

Back to original problem that started this thread. The PRIVATE inheritance
of a parent_type as given in 98-198 (EXTENDS, PRIVATE::parent_type).
It would be possible to do so but only with the constraint that such an
extended type (and all its descendants) cannot be used in (all,certain?)
polymorphic assignments. I haven't given it any more thought. I don't know
(yet) how C++ handles such a construct (where this seems to originate from).

Cheers,
WWS
-----------------------------------------------------------------------
| Werner W Schulz                                                     |
| Dept of Chemistry                  email:     [log in to unmask]       |
| University of Cambridge            Phone:     (+44) (0)1223 336 502 |
| Lensfield Road                     Secretary:          1223 336 338 |
| Cambridge CB2 1EW                  Fax:                1223 336 536 |
| United Kingdom                     WWW:                             |
-----------------------------------------------------------------------



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%