# A question about the OO style
**URL:** https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354
**Category:** Help
**Created:** [October 19, 2020, 3:47am UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354 "2020-10-19T03:47:17Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@han190](https://fortran-lang.discourse.group/u/han190)
#### Post date: [October 19, 2020, 3:47am UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/1 "2020-10-19T03:47:17Z")
Hi, guys. I need some help here!
Suppose I have a module like this,
Should I use the style I commented or should I use the original version, and which one is better?
---
### Author:  [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)
#### Post date: [October 19, 2020, 2:18pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/2 "2020-10-19T14:18:26Z")
While I am no specialist for Fortran OO programming, I believe the compiler will produce the same code in both cases.
Personally, I prefer the first one because it is shorter. But since `average_func` does not actually use any internals from `this` (unused dummy argument) the question arises why make it available through the derived type.
In cases where you need to access many members of your derived type (and reuse them) you can also use an associate construct:
```auto
function covariance_func(self,x,y) result(ret)
class(test_t), intent(in) :: self
real, intent(in) :: x(:), y(:)
real :: ret
associate(ax => self%avg(x), ay => self%avg(y))
ret = self%avg((x - ax)*(y - ay))
end associate
end function
```
In this short example however, it is not that useful.
---
### Author:  [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)
#### Post date: [October 19, 2020, 3:27pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/3 "2020-10-19T15:27:52Z")
In the case of this example, the OO style here is overkill. Unless you expect someone to extend your type and provide a different implementation for `average_func` (which I think can’t actually be done since you’ve marked it private), then there’s no reason reason to call the function through the object. In fact, this implementation will (likely) be slower, because it needs to do a VTable lookup to find the function implementation at runtime, because as far as the compiler knows, you may have passed in a child type with a different implementation.
---
### Author:  [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)
#### Post date: [October 19, 2020, 3:53pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/4 "2020-10-19T15:53:21Z")
> [@han190](#):
>
> Should I use the style I commented or should I use the original version, and which one is better?
@han190,
For what you show, please note for the typical applications of Fortran in scientific and technical computing, you’d use neither of your options nor an OO-style at all, though one of the key aspects of OO with `information hiding` can still be employed with MODULE-based programming. Rather, Fortranners will expect a functional programming style along with the powerful option in Fortran with PURE keyword that can also help `consumers` of your code.
Another consideration will be to bring in as much as generic programming as reasonably possible considering the limitations of Fortran. So in this instance, you can think of bringing in KIND genericity.
Also, @ivanpribec’s suggestion of the ASSOCIATE construct can come in really handy with performance for medium to large datasets up to a certain size depending on the processor. Here’s an example:
```Fortran
module kinds_m
use, intrinsic :: iso_fortran_env, only : real_kinds
! A processor can be expected to support at least 2 kinds of REAL, perhaps more
integer, parameter :: RK1 = real_kinds(1), RK2 = real_kinds(2)
end module
module stats_m
use kinds_m, only : RK1, RK2 ! elided is support for more kinds
private
generic, public :: avg => avg_rk1, avg_rk2
generic, public :: cov => cov_rk1, cov_rk2
contains
pure function avg_rk1( x ) result( r )
! Argument list
real(rk1), intent(in) :: x(:)
! Function result
real(rk1) :: r
r = sum(x)/size(x)
return
end function
pure function avg_rk2( x ) result( r )
! Argument list
real(rk2), intent(in) :: x(:)
! Function result
real(rk2) :: r
r = sum(x)/size(x)
return
end function
pure function cov_rk1( x, y ) result( r )
! Argument list
real(rk1), intent(in) :: x(:)
real(rk1), intent(in) :: y(:)
! Function result
real(rk1) :: r
associate ( avg_x => avg(x), avg_y => avg(y) )
r = avg( (x - avg_x)*(y - avg_y) )
end associate
return
end function
pure function cov_rk2( x, y ) result( r )
! Argument list
real(rk2), intent(in) :: x(:)
real(rk2), intent(in) :: y(:)
! Function result
real(rk2) :: r
associate ( avg_x => avg(x), avg_y => avg(y) )
r = avg( (x - avg_x)*(y - avg_y) )
end associate
return
end function
end module
program p
use stats_m, only : avg, cov
blk1: block
real :: x(3), y(3) !<- default real; likely will map to RK1
x = [0.45, 0.5, 0.55]
y = [0.95, 1.0, 1.05]
print *, "Block 1: working with precision of ", precision( x(1) )
print *, "avg(x) = ", avg(x)
print *, "cov(x,y) = ", cov(x,y)
end block blk1
print *
blk2: block
integer, parameter :: RK = selected_real_kind( p=12 )
real(RK) :: x(3), y(3) !<- likely will map to RK2
x = [0.45_rk, 0.5_rk, 0.55_rk]
y = [0.95_rk, 1.0_rk, 1.05_rk]
print *, "Block 2: working with precision of ", precision( x(1) )
print *, "avg(x) = ", avg(x)
print *, "cov(x,y) = ", cov(x,y)
end block blk2
stop
end program
```
Upon execution with a commercial compiler, the output is as expected:
> C:\Temp\>ifort /standard-semantics /warn:all /stand:f18 p.f90
> Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.2.254 Build 20200623
> Copyright (C) 1985-2020 Intel Corporation. All rights reserved.
>
> Microsoft (R) Incremental Linker Version 14.26.28806.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> -out:p.exe
> -subsystem:console
> p.obj
>
> C:\Temp\>p.exe
> Block 1: working with precision of 6
> avg(x) = 0.5000000
> cov(x,y) = 1.6666665E-03
>
> Block 2: working with precision of 15
> avg(x) = 0.500000000000000
> cov(x,y) = 1.666666666666669E-003
>
> C:\Temp\>
---
### Author:  [@han190](https://fortran-lang.discourse.group/u/han190)
#### Post date: [October 19, 2020, 4:26pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/5 "2020-10-19T16:26:37Z")
@everythingfunctional, @FortranFan
Hi, thanks for the reply! I am aware this is an overkill. I guess I didn’t make my question clear. I am wondering should I use the style `self%func(a, b)` or `func(this, a, b)` if I want to call a type-bound procedure in a type-bound procedure? I am definitely not going to use this implementation in my code nor will I frequently use OO style in scientific computing. I am just curious if the compiler will treat these two styles differently?
---
### Author:  [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)
#### Post date: [October 19, 2020, 7:31pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/6 "2020-10-19T19:31:17Z")
> [@han190](#):
>
> I am wondering should I use the style `self%func(a, b)` or `func(this, a, b)` if I want to call a type-bound procedure in a type-bound procedure?
This Dr Fortran [**blog**](https://stevelionel.com/drfortran/2020/06/30/doctor-fortran-in-not-my-type/#more-359) may be of more help to you as well as other readers here. Especially the “under the hood” section:
> if you pass a non-polymorphic variable to a polymorphic dummy argument ( `class()` ), the compiler has to construct a class descriptor at the point of the call. Yes, there are optimizations that can be done, but this is still a complex operation that can generate hundreds of instructions. Try not to do this a lot if performance is a goal.
Check and verify with your compiler always, but if you can avoid situations such as above, you should be alright.
---
### Author:  [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)
#### Post date: [October 19, 2020, 7:56pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/7 "2020-10-19T19:56:35Z")
> I am wondering should I use the style `self%func(a, b)` or `func(this, a, b)` if I want to call a type-bound procedure in a type-bound procedure?
If you’re calling a type-bound procedure, use the OO syntax. If you don’t, it obfuscates the fact that it is a type-bound procedure and that the overhead of polymorphism is involved.
---
### Author:  [@septc](https://fortran-lang.discourse.group/u/septc)
#### Post date: [October 24, 2020, 8:13pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/8 "2020-10-24T20:13:18Z")
Though not very sure, apart from performance, isn’t it related to “dynamic vs static” dispatch things? For example, the following code gives different results when using “self % func()” vs “func( self )”.
```auto
module test_m
implicit none
type Parent_t
contains
procedure :: sub
procedure :: func
endtype
type, extends(Parent_t) :: Child_t
contains
procedure :: func => Child_func !! overrides Parent's "func"
endtype
contains
subroutine sub( self )
class(Parent_t) :: self
print *, self% func() !! --> 200 (via dynamic dispatch)
! print *, func( self ) !! --> 100 (via static dispatch)
end
function func( self ) result( ret )
class(Parent_t) :: self
integer :: ret
ret = 100
end
function Child_func( self ) result( ret )
class(Child_t) :: self
integer :: ret
ret = 200
end
end
program main
use test_m
implicit none
class(Parent_t), allocatable :: p
allocate( Child_t :: p )
call p % sub()
end
```
(Apart from OO, I use a similar thing to create a “module type” that contains various module procedures and used to allow module\_name % module\_proc().)
---
### Author:  [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)
#### Post date: [October 25, 2020, 1:53pm UTC](https://fortran-lang.discourse.group/t/a-question-about-the-oo-style/354/9 "2020-10-25T13:53:12Z")
> [@septc](#):
>
> For example, the following code gives different results when using “self % func()” vs “func( self )”.
Note this can be a `gotcha` with the OO paradigm generally but also with Fortran.
In the case of Fortran, coders - if they wish to be careful - can provide the `binding-name` along the lines of a generic name and employ distinct `procedure-name`s which will help prevent such ambiguities e.g.,
```Fortran
..
type Parent_t
contains
procedure :: sub
procedure :: func => Parent_func
end type
..
```
in which case the following will not work and the processor will issue a diagnostic:
```auto
subroutine sub( self )
class(Parent_t) :: self
..
print *, func( self ) ! will not compile
```
whereas `self%func()` or `Parent_func( self )` will be alright and the result will be consistent with how the program was authored whether the writer’s intent was subconscious or conscious!