[J3] [EXTERNAL] Elemental type-bound functions not useful

Clune, Thomas L. (GSFC-6101) thomas.l.clune at nasa.gov
Tue Mar 30 12:59:42 UTC 2021


The depth of a chain of type extensions really should depend on the specifics of the use case.   Certainly there is always some value to having a purely abstract base class, as it enables loose coupling with client code.    And limiting the chain is only wise given the observed fragility in most compilers even at this far remove from 2003

But there are common situations that require a few more degrees of inheritance are quite appropriate.         As a specific example,  the Java unit testing framework JUnit has an internal chain of classes:

  *   SelfDescribing (pure abstract)
  *   TypeSafeSelfDescribing (concrete instantiation for handling incompatible arguments to the primary method)
  *   Matchable (still abstract, but adds virtual method for comparing an object with anything else -- class(*)

Users then extend Matchable in their own unit tests to wrap their own types.   This allows the user to exploit the powerful grammar for composing diagnostic messages for failing tests.   This is a perfectly reasonable (and highly successful!) OO design.  And I don’t think it is the deepest such chain in the framework.

Alas, the Fortran analog of the above breaks gFortran when I have an almost trivial extension of Matchable and then an extension of the extension.   (Needed to test the ability to store objects of any dynamic types within one of my container classes.)   And this is without even trying to emulate the ultimate base class “Object” that is underlying Java.      So a major driver for OO design shifts form maximizing power/expressiveness to keeping it simple so as to remain portable across multiple compilers.      Sigh.


From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Monday, March 29, 2021 at 9:34 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Damian Rouson <damian at sourceryinstitute.org>, j3 <j3 at j3-fortran.org>
Subject: Re: [J3] [EXTERNAL] Elemental type-bound functions not useful



On Mon, Mar 29, 2021 at 6:11 PM Van Snyder via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

Fortran doesn't yet have "sealed" or "inextensible" types (unless I missed something that prevents creating an extension type).

One can prevent type extension by declaring a type-bound generic procedure with the same name as the name of the type as one might do to effectively write a type-bound, user-defined structure constructor:

type foo
contains
  procedure :: foo_constructor
  generic :: foo => foo_constructor
end type

My thoughts are aligned with those of Tom and Vipul.   Once Fortran supports generic programming, I suspect it will displace type extension for most of my purposes. For now, I strive to limit type extension to extending abstract types. We sometimes have a non-abstract type extending an abstract type that extends another abstract type, but that's as deep as our hierarchies go in practice.  We frequently combine type extension with type-bound operators, but I'm not crazy about the type-guarding that this approach requires. It feels like the developer is being burdened with ensuring runtime type safety as a stand-in for compile-time type safety, which is why I suspect I'll replace type extension with generic programming.

Damian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210330/fe49d494/attachment-0003.htm>


More information about the J3 mailing list