> On Mar 25, 2018, at 4:22 PM, Vipul Parekh <[log in to unmask]> wrote:
> Thanks for your comments.
> On Sat, Mar 24, 2018 at 11:24 AM, Clune, Thomas L. (GSFC-6101)
> <[log in to unmask]> wrote:
>> ..I’m mostly happy with the current system, modulo the many bug reports on type-bound assignment I’ve had to submit over the years. It meshes well with similar treatment in other OO languages.
> Fyi, I replied in another in note to Bill's comments there are gaps
> and limitations in Fortran relative to other programming options for
> OO, say those that make it to the top 5 on the Tiobe Index and as
> such, I'm mostly unhappy with where things stand with Fortran.
There are many additional OO features which I would like to have. My comment was really specific to how overloading of assignment works.
>> My one complaint, which is broader than just assignment, is that the specific names for type-bound procedures must be identical in subclasses that want to override something. ..
> However can you please elaborate on this specific name issue? I would
> have thought this was one aspect where Fortran does alright with '=>'
> renaming option.
The “=>” operator does allow one to have different type-bound names than actual procedure names. But the issue I was raising is slightly deeper than that.
Suppose you have a base class that defines a generic type-bound procedure, say FOO with specific type-bound procedures FOO_int and FOO_real. If you then have a subclass where you wish to override the interface FOO_int, then you need to have the _same_ type-bound procedure name in the subclass. With “=>” the actual procedure name can be something different, but the actual code explicitly references the name from the base class:
PROCEDURE :: FOO_int => <actual-procedure-name>
And if the base class only makes the generic FOO public, then the subclasses cannot override those interfaces at all.
There are 2 annoyances here. First is the need to look at the parent hierarchy to find the specific name you want to override. With good style, this is sometimes “obvious”, but sometimes the names need to be a fair bit more arbitrary. Second, a person reading the code for the child subclass may not even realize that a generic name is available.
These do not fundamentally impact OO design, so the are fairly far down on my list of OO concerns. Things that are more important to me: (1) The lack of an analog to Java’s ‘interface” combine with Fortran being a single-inheritance language makes some OO designs rather cumbersome in Fortran. (2) Tthe lack of forward declarations (ala C++) sometimes requires multiple base classes to be declared in the same module, and hence in the same. It is hard to say that this is a fundamental issue, but it clashes badly with otherwise sensible naming conventions for files. (If the classes and methods are all abstract, then something reasonable can be done with include files, but if there are any non-abstract methods on the base classes one needs two sets of include files: those for type and interface declarations before CONTAINS and those for procedure definitions after the CONTAINS. Been there done that.)
> Vipul Parekh