I’m trying to call a procedure of an abstract derived type, that I’ve extended from, but from within a procedure that overrides that procedure of the parent type. I.e. the following MWE: module parent_m implicit none private public :: parent_t type, abstract :: parent_t contain…

[image] everythingfunctional: … Could anyone point me to the place in the standard that makes this restriction and explain why this restriction is necessary? @everythingfunctional , From what I recall, the restriction comes into effect by deductive reasoning: for type-bound procedures, secti…

I can see how reading that section one could come to the conclusion of that constraint, but is it technically necessary? Could an exception be made for this case? Or is there something I’m missing. It seems pretty clear to me what procedure is intended to be called, but maybe there are edge cases I…

I should add there is additional deduction based on an inferential process that comes into play with type extension. Under section 7.5.7.2 Inheritance, paragraph 2, the standard states, “An extended type has a scalar, nonpointer, nonallocatable, parent component with the type and type parameters of…

[image] everythingfunctional: I can see how reading that section one could come to the conclusion of that constraint, but is it technically necessary? … Re: “is it technically necessary?”, unless I’m overlooking something, I think the answer is yes. I think the reasoning for this will be one…

[image] FortranFan: I think the reasoning for this will be one cannot construct self-standing objects of an abstract type given there can be deferred procedures with said type; and because the semantics of "…%parent%…` reference is set up to resolve to a specific binding, it can lead to a hole t…

[image] everythingfunctional: I’m not sure I would consider ...%parent%.. to be a self-standing object … Requiring the details of the initial implementation be made public and the logic duplicated seems to me like bad code design solely due to a poor language design decision… Note my point i…

[image] FortranFan: ’m not sure I understand the issue here re: “implementation be made public”. In the example say_hello is public, but what it does/how it does it is not. In more complex examples there may be local parameters, private module procedures that one does not necessarily desire t…

[image] everythingfunctional: … In more complex examples there may be local parameter s, private module procedures that one does not necessarily desire to make public, and complex internal logic that one would prefer not to duplicate. When I wrote above “OO facilities in Fortran can do with s…

[image] everythingfunctional: subroutine init(self) class(child), intent(inout) :: self call self%parent%init ! and now set up some child specific stuff too end subroutine Requiring the details of the initial implementation be made public and the logic duplicated seems to me like bad cod…

Call overridden procedure of abstract parent type

Help

everythingfunctional January 20, 2021, 3:49am 8

Also, once I’m done with the workaround, I’ll come back and point to it. It’s in an open source project.

Topic		Replies	Views
Parameterized derived types and type extensions Help	18	720	September 8, 2025
Abstract type and derived types - a problem with sample code Help	6	1070	March 27, 2022
Polymorphic behavior of derived types	6	1260	October 13, 2022
Inheritance problem; or, selectively accessing procedures of parent class	12	425	February 7, 2024
Abstract type with private deferred type-bound procedures	6	419	November 28, 2024

Call overridden procedure of abstract parent type

Related topics