(j3.2006) NAME= for internal procs
Richard E Maine
Wed Jan 10 11:02:09 EST 2007
On Jan 9, 2007, at 11:07 PM, Aleksandar Donev wrote:
> Concerning UTI 103 (page 330) and whether NAME="" should be
> required for
> interoperable internal procedures. I was under the impression that for
> PRIVATE module procedures that are interoperable we required
> NAME="" to
> be specified. But looking at the document I cannot find support for
> recollection. What do we do about private interoperable procedures and
> binding labels?
I don't recall anything about requiring NAME= for interoperable
private module procedures. This could, of course, be a failure of my
recollection, but I also don't see any reason why it should be
required. The existing rules look to me to work fine and be sensible.
Unless someone actually finds such a rule, I would say that the
interpretation is pretty clear - that there isn't one and there is
inadequate reason to retroactively make such an incompatible change.
My personal inclination would be that if internal procedures are
allowed to be interoperable, they should be like module procedures in
this regard, not requiring the NAME=. Seems to me that the issues
involved are similar and that there is no overwhelming need for a
requirement. Yes, there are potential name conflicts if you have
multiple internal procedures of the same name (with different hosts,
of course). But requiring NAME= doesn't solve that, as there can
still be the same kind of name conflict if the multiple internal
procedures specify the same binding label using NAME=. The existing
rules seem to me to cover all this just fine; the name conflicts in
both cases illegal code, which could be fixed by changing some of the
binding labels either by changing some of the procedure name (and
thus the default binding labels), or by appropriate use of NAME=.
But the internal procedure case isn't a matter of retroactive change
incompatible with a published standard. It seems more open to debate.
Unless I've missed something, the above would be my position in such
a debate, but it isn't as strong as what I'd say about private module
procedures. For private module procedures, I'd argue that they
shouldn't even be considered debatable (unless, again, I missed where
the requirement is in the published f2003 standard).
Richard Maine | Good judgment comes from experience;
Richard.Maine at nasa.gov | experience comes from bad judgment.
| -- Mark Twain
More information about the J3