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

[Van Snyder]

On Tue, 2021-03-30 at 14:41 +0000, Bill Long via J3 wrote:
> In (partial) defense of Van, we did encounter a C++ code that had
> nested classes more that 75 layers deep, breaking the debugging tool
> the customer was using.   While restricting nesting to just 1 level
> might be too extreme, programmers should show some sense of
> restraint.   And gratuitous abstraction can make code unreadable and
> unmaintainable, especially when the error is in a layer of nesting
> above the ones you wrote. 

I appreciate that Bill is of a mind to defend me, but advocating deep
class hierarchies was not my position. I only worried about one
extension making a type-bound elemental function worthless and
dangerous.
I've only ever used one extension. The base class provided a
representation and elementary methods such as "add an item to the
structure." The extension provided methods for a specific problem
(sparse interpolation).
> Cheers,Bill
> 
> > On Mar 30, 2021, at 7:59 AM, Clune, Thomas L. (GSFC-6101) via J3 <
> > j3 at mailman.j3-fortran.org> wrote:
> > 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>D
> > ate: Monday, March 29, 2021 at 9:34 PMTo: 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> 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 foocontains  procedure ::
> > foo_constructor  generic :: foo => foo_constructorend 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
> 
> Bill
> Long                                                                 
>       longb at hpe.com
> Engineer/Master , Fortran Technical Support &   voice:  651-605-
> 9024Bioinformatics Software
> Development                      fax:  651-605-9143Hewlett Packard
> Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210330/9f00ca76/attachment.htm>