(j3.2006) US-04 Control host association
Van Snyder
Van.Snyder
Thu Aug 15 19:14:32 EDT 2013
On Thu, 2013-08-15 at 18:54 -0400, Rafik Zurob wrote:
> Van Snyder wrote on 14/08/2013 10:43:15 PM:
> ...
> > Would it be feature creep to include renaming?
>
> IMHO, yes. Modules are separate compilation units that the user might not
> have control over, and so renaming in USE is sometimes necessary. e.g If
> USEing multiple modules that provide the same entity name. But host
> association only applies to entities in the same compilation unit (and
> submodules), so the user should be able to use unique names without
> renaming on import.
This came up in a context where it was desired to copy a module
procedure from one module to another, and then revise it substantially
for a similar but not identical purpose. The entity desired to be
renamed for access by host association in the module procedure was a
module variable (or maybe a named constant -- I forget which). It was
desired to access the module entity by host association but avoid a
conflict with an entity of that name in the to-be-moved procedure.
Changing its name in the module would have entailed changing (and
recertifying) dozens of other modules, to use the new name and rename it
to the old. The procedure was of non-trivial size, so changing the name
of the local object having the same name as the module variable would
also have been non-trivial.
If I remember correctly, the solution was to create two modules, putting
the to-be-moved procedure in a different module from the object it
needed, and renaming during USE. This entailed making a bunch of stuff
public that should not have been.
Renaming during access by host association would have been a cleaner
solution. It would be especially useful to access entities from parent
modules into submodules.
People have asked to be allowed to USE a module from within a scope
within the module, precisely to be able to rename module entities that
would otherwise be gotten by host association.
> So the requirements section of 13-238r1 looks reasonable to me.
>
> Regards
>
> Rafik
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
More information about the J3
mailing list