On 7/27/2017 11:02 PM, Vipul Parekh wrote:
> Can other readers please chime in and indicate their views on this?
By convention, I am a year older and wiser today, so I will offer my
$.02 on the issues discussed under this subject heading:
1. There is a great deal of similarity between the functionality offered
by the intrinsic functions SAME_TYPE_AS and EXTENDS_TYPE_OF and that
offered by the type guards TYPE IS and CLASS IS in a SELECT TYPE
construct. The semantics of the type guards is more precisely defined,
and more usefully defined (in my opinion). Additionally, because SELECT
TYPE is used more often, I expect its performance to be more likely to
be optimized. All of this says to me that one should never use the
intrinsic functions if the information you are seeking can be obtained
with SELECT TYPE. (I believe this may be true of the example that
started this discussion.) In practice, this means that these two
intrinsic functions should only be used when their MOLD arguments are
polymorphic with a dynamic type unknown at compile time.
2. In the interest of making the language easier to learn and remember,
I strongly prefer consistency over inconsistency. Thus, I would tend to
oppose a version of SAME_TYPE_AS in which kind was significant for
intrinsic types, but not for derived types or vice versa, or if
SAME_TYPE_AS treated kinds as significant while EXTENDS_TYPE_OF did not
or vice versa.
3. My personal preference would be that kinds were significant in these
two intrinsic functions, for consistency with SELECT TYPE (see #2), to
allow their implementation to make use of the infrastructure created to
implement the type guards, and because the functionality ignoring kinds
appears to me to be useless. My impression as a member of J3 and its
OOP subgroup for most (but not all) of the period in which F2003 was
developed, is that there was no conscious decision to ignore kind in
these intrinsic functions, just a failure to reconcile them with PDTs in
the same way SELECT TYPE was. [I will concede this point if someone can
offer evidence that J3 actively considered whether kinds should be
significant in these intrinsic functions before the adoption of F2003,
or if someone can identify a class of usage where it is actually useful
to ignore kinds.]
4. For all the implementation strategies I know that adequately address
the performance of the type guards in SELECT CASE, it should be possible
to implement the two intrinsic functions treating kind as significant
with no serious performance issues. Of course, that may simply mean
that I have not thought of a sufficiently perverse implementation in
which this is not true.
-Kurt
|