(j3.2006) 08-267
Aleksandar Donev
donev1
Wed Sep 24 13:10:37 EDT 2008
Van and Jim,
I will repeat, and Bill gave you the reference: The dynamic type must be the
same on all images. This is by design. So Van's code:
> > ? class(my_type), intent(in) :: x[*]
> > ? select type ( x )
> > ? type is ( my_extension )
> > ? ? print *, x[1]%extra_stuff
> > ? end select
is perfectly fine and it is the way to do what he wants (access components of
the extended type on other images).
Jim pondered:
> Hmm..., I don't even understand what this code fragment means: the
> associate name, x, in the select type construct is revering to a local
> variable
It refers to a coarray, i.e., a variable with corank 1. Sure, the variable
is "local", all variables are, seing as how there is no concept of a "global"
variable (not in this revision, thank you very much!).
> I think we should prohibit coindexed objects with base-object
> being associate name.
Why? The code makes perfect sense to me, and as I said, putting in arbitrary
restrictions is a vv bad design idea. There may be good reasons to eliminate
all mingling of ASSOCIATE and coarrays, but I don't see it in your post. We
did prohibit the selector from being coindexed with good reasons.
I understand you hate ASSOCIATE and polymorphics because of the pains they
cause to implement. IBM can simply not implement them, or should have
objected in 2003. Now is not the time to backwards remove language elements
we dislike (otherwise I will promptly send my list as well).
Best,
Aleks
--
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816 Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev
More information about the J3
mailing list