3

In Fortran 2003, if an variable is declared as PRIVATE in a superclass, the subclasses will not be able to access it. But if all the variables are declared as PUBLIC, the program will lose the property of 'information hidding'.

Is there any way to take both 'data inheritance' and 'information hidding' in Fortran object-oriented programming? If not in 2003, is there any improvement in Fortran 2008?

shuttler
  • 67
  • 6
  • In Fortran terminology "super class" is "parent [derived] type", subclass is "extended type". – IanH May 23 '13 at 00:55

2 Answers2

3

My understanding is that, in Fortran 2003, any private components of a derived type defined in a module are directly accessible within that module. One implication (which I have not tested) is that those private components are directly accessible from sub-types defined in the same module but not from sub-types declared in another module. As I say I have not tested this and stand to be corrected.

If you have a compiler which implements sub-modules then the private components are also directly accessible in descendant submodules. I think sub-modules were introduced in a technical report after the publication of the 2003 standard and are now included in the 2008 standard but that not many of the widely-used compilers implement the feature.

Notwithstanding the standards it's not clear to me how much one loses by not having direct access to private components of super-types. In the object-oriented world it seems to be very common to make all components private (though other languages use other words to express the idea) and to provide access only through accessor methods -- in Fortran terms they would be procedures for assigning to or for returning the value of private components. This strict separation of internal data representation from external access permits changing the internal representations without changing how other procedures access the data, and this separation is generally thought to be a good idea.

The use of accessor procedures also permits a more fine-grained and subtle application of access control, for example by providing a procedure which sets the value of a component when an instance of a derived type is constructed but no procedure to modify the value of the component thereafter.

Private components with public accessor procedures seem to me to provide most of both data inheritance and information hiding but I'll be interested to read other answers to the question.

IanH
  • 19,836
  • 2
  • 31
  • 52
High Performance Mark
  • 74,067
  • 7
  • 97
  • 147
  • I tested what said in your first paragraph. You were correct. – shuttler May 22 '13 at 23:12
  • Declare a sub-type in another module may be more useful, because we do not want to change what has been done. For example, in a 2-D problem, I declare a super-class with variables x,y, and then I want to extend it to a 3-D sub-class with a new variable z. If z has nothing to do with x and y, everything is fine. But if z has to interact with x and y, the coding will be a little cumbersome, although, it is still doable. I agree with what you've said. This design is actually a good idea. I am just wondering whether there happen to be an easy way to solve the problem I stated above. – shuttler May 22 '13 at 23:20
  • I think the easy way to avoid the disciplined use of accessor methods is to go on holiday for a year or so and return to work when your favourite compiler has been updated to implement sub-modules. Either that or buy into the philosophy that all components should be private and only ever accessed by procedures. But, to be serious, I've been doing a lot of o-o programming in Fortran recently and have not yet encountered the issue you identify as a problem. Like you I can conceive of toy situations but in practice it's not yet been a problem. – High Performance Mark May 22 '13 at 23:30
  • The situation I described actually is exactly what I am facing now. That's not an imaginary toy. As you said, I think I have to accept the fact or wait until submodule is implemented. – shuttler May 22 '13 at 23:37
  • In "typical" use case (well, as typical as it can be given the paucity of implementations - and use-case exceptions do exist) submodules here are only going to help in that they reduce the size of the source code in the module proper. A type defined *in* a submodule isn't going to be available to other program units, apart from descendants of that submodule - i.e. your 3D sub-class can't be used in any other module. That may not suit. – IanH May 23 '13 at 00:53
  • @lanH: It sounds like even submodule cannot solve the problem. In my case, both x and y are large arrays. If I read the whole arrays out at one time, I need more memory storage. If I get the values one by one, I think I will lose some performance because the calculation cannot be vectorized in that way. The worst thing is both memory and performance are concerns in my case. – shuttler May 23 '13 at 15:51
0

Unfortunately, there is no direct way in Fortran to define components of a derived type being accessible from type bound procedures of extending derived types but hidden otherwise. As High Performance Mark pointed out, the access of the derived type components is based on modules: Private components of a derived type can only be accessed from within that module.

The pragmatic solution is to define everything public which should be accessible from outside, irrespective whether you want to use those components in extending derived types only or also elsewhere. Private and public in this concept only decides, whether you can change internal details (private) or not (public) without having to be worried about consequences for other parts of your or somebody elses code.

Also, please note, that even having a language feature like the protected members in C++, would not solve the basic problem: Once you declare something not being private, changing its behaviour will cause side effects in other codes, which you eventually are not even aware of (e.g. somebody extending your derived type and relying on the behaviour of some members being accessable from extending types.)

Community
  • 1
  • 1
Bálint Aradi
  • 3,534
  • 13
  • 21