(j3.2006) Finalization ordering question

[Bill Long]

Jim Xia wrote:
>
> >    There remains the question of what the committee wants to do 
> about it
> > now.  I see three possibilities:
> >    a. Leave the ordering as it stands.
> >    b. Completely remove that part of the ordering.  This could be done
> > by removing "(3)" and making what is now step (3) a part of step (2) 
> [in
> > effect, a statement that the parent component is one of the components
> > covered by step (2)].
> >    c. The ordering between extended components and parent components
> > could be interpreted (and textually clarified) to apply on a per 
> element
> > basis.  [I.e., the extended components of an element are to be 
> finalized
> > before the parent component of that element, but not necessarily before
> > the parent components of other elements.]
> >
> > My first choice would be (b), but I would find (c) acceptable.
>
>
> Sorry Kurt, you've just got a no vote from me.  It's too late to 
> change rules now after we've implemented them all.  IMHO the current 
> text of the finalization process is clear and unambiguous.   

So, when you say that the rules are clear, I assume you mean that the
parent component finalizer is called for the whole base array, not
elementally. Right?

Cheers,
Bill




> The sequence of the actions that should take place during a 
> finalization is well defined.  Although I don't like them personally, 
> I don't see a need to give this topic a respin.  As to the issue of 
> performance in finalization process, where I believe this thread of 
> arguments was originated from, I think one needs to look at the whole 
> picture of the finalizer rather than focusing on the specific ordering 
> requirements.  I maintain my opinion that the real performance buggers 
> with regard to finalization are not from how the finalizations are 
> processed, but rather how much related code a programmer has to write 
> in order to use them safely and effectively (e.g. a programmer has to 
> write (almost certain the elemental) defined assignment, and also a 
> function that overrides the structure constructor).  If there is 
> anything to consider by the committee at this point, I'd rather prefer 
> reconsidering the ramifications of interp F03/062 -- finalization for 
> array constructors.
>
>
> Cheers,
>
> Jim Xia
>
> XL Fortran Compiler Testing
> IBM Toronto Lab at 8200 Warden Ave.
> Phone (905) 413-3444  Tie-line 969-3444
> D2/NAH/8200 /MKM
> ------------------------------------------------------------------------
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   


-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120