(j3.2006) Implicit assignment of objects of extended types

[Tom Clune]

All,

Apologies for the extra bandwidth, but I never saw any responses to my email to the list on Oct. 16th.   Granted, it was poorly timed  as it coincided with the meeting wrapping up in  Las Vegas.    

I?m specifically interested in whether my point (1) below carries any weight with regard to how we should proceed with the interp request.

Cheers,

- Tom



> On Oct 16, 2015, at 9:41 AM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:
> 
> Attached below is a motivating example of my objection to the interp we discussed on Tuesday. (Paper 218 I think.)
> 
> I also have a few additional arguments to bolster my case.
> 
> 1)  If I understand correctly, the semantics of finalization work on the base object, not on the components of the base object.  In 15-007r2.pdf  4.5.6.2 The finalization process (78:19), we have:  
> 
> ?If the entity is of extended type and the parent type is finalizable, the parent component is finalized.?
> 
> The proposed interp seems to run contrary to this treatment of the base as a coherent entity.
> 
> 2) Not that it really matters, but C++ implicit copy/assignment semantics also use the copy/assignment operator for the base object, not its components.
> 
> 3) Just to reiterate my point on Tuesday.   The proposed interp in 218 adds considerable burden to implementors of type extensions.   If a base type overrides default assignment, then the type extension almost certainly must as well, or risk ruining some invariant property that the base otherwise preserves.  Further, this burden propagates down the inheritance hierarchy.  Perhaps on some occasions, the implementor may find that default assignment is actually ok, but it would require looking ?inside? the base type implementation.  (And I cannot construct a plausible motivating example of this situation, though I?ve also not tried very hard.)
> 
> 
> 
> 
> Thomas Clune, Ph. D. 
> <Thomas.L.Clune at nasa.gov <mailto:Thomas.L.Clune at nasa.gov>>
> Software Infrastructure Team Lead
> Global Modeling and Assimilation Office, Code 610.1
> NASA GSFC 
> MS 610.1 B33-C128
> Greenbelt, MD 20771
> 301-286-4635
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> <intrinsic_assignment.F90>

Thomas Clune, Ph. D. 	<Thomas.L.Clune at nasa.gov>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC		
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635













-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20151117/19a9754a/attachment.html