Lawrie Schonfelder wrote:
> If duplication was allowed you could have
>
> module a
> Interface
> !complete interface declaration for proc b
> endinterface
> end module a
>
> subroutine b(....)
> USE a
> !complete declaration of b
> ...
> end subroutine b
>
> This would still enable separate compilation of b, but not independent.
>
> I think this simple relaxation of an unnecessary restriction provides much
> if not all of what Van is trying to get.
While I agree that allowing duplicate interface definitions is a good thing,
doing so doesn't appear to attack the problems that stimulated me to write
98-104.
Maybe I'm missing something, but I don't see how this allows me to break
a module into several pieces, while retaining access to module-private
entities (including private components of public types) from within every
piece, and change a procedure body or other module-private entity without
depending on so-far-unfulfilled promises that "quality of implementation"
will prevent a re-compilation and re-certification cascade.
Even if this proposal solves those problems, it still needs one addition:
Interface bodies need to be able to get at their host environment.
Otherwise, it's not possible to get a definition of a derived type into
them. Yes, you can put the type definition in a different module, and USE
it in the interface body, but this introduces new problems related to
private components.
Best regards,
Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|