[J3] [EXTERNAL] Re: Remove requirement that passed-object dummy argument is required to be scalar?

[Clune, Thomas L. (GSFC-6101)]

In practice, it is often more useful to put this responsibility in the object that “has-a” list, as it is the object that “knows” how it wants to navigate.   Different subclasses of _that_ object can then navigate differently.

I’m not saying that this covers all scenarios, of course, but you might want to examine your design to see if that pattern works instead.



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: Thursday, December 9, 2021 at 9:28 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Van Snyder <van.snyder at sbcglobal.net>
Subject: [EXTERNAL] Re: [J3] Remove requirement that passed-object dummy argument is required to be scalar?

On Thu, 2021-12-09 at 23:15 +0000, Brad Richardson via J3 wrote:
How would the procedure be called with a scalar then? I.e.

type(list_t) :: my_list

...

if (my_list%check_list()) then
 ...

If it's called with a scalar, e.g. "call list%check_list," then the check_list procedure can't access the previous and next items because it doesn't have access to the array.

I think to remove the constraint would require new features to deal with all these kinds of cases.

I'm not sure what other cases would need attention. I didn't read the whole standard again, but in my superficial study, I couldn't find anywhere that "scalar" vs, "array" for the passed-object dummy argument would make a difference -- except in C760.

On Thu, 2021-12-09 at 15:06 -0800, Van Snyder via J3 wrote:
Is there a technical reason that the passed-object dummy argument is required to be a scalar?

In an old code, have a module with a "list" type that manages double-linked lists, where the links are subscripts in an array of "list" type. The current version of the "list" type has a single additional "item" component of type integer that is a subscript into another array. I'd like to extend the list type to incorporate a component of that other type (or its its components), rather than needing two types, and needing to connect the objects using subscripts. This would be trivial using a parameterized module instead of type extension.

One of the module procedures checks that the list is consistent, by verifying that the "next" component of the previous list item is in fact the current item, and the same for the next one.

If something goes wrong, it calls another procedure to dump the list item -- along with its predecessor and successor.

I can't make those procedures  type-bound procedures because the passed-object dummy argument is required to be a scalar.

Therefore, I can't inherit those procedures into extension types, and override them.

A work-around kludge is to make "list" have a single array component that is the real list. This adds another level of component selection in every reference.

Another kludge is to use pointers to scalar "list" objects, instead of subscripts, but that's an invitation to memory leaks because we don't have reference-counted targets or intrinsic garbage collection.

If there is no compelling reason that the passed-object dummy argument is required to be a scalar, can that clause of C760 be removed?


  logical function Check_List ( List, Message ) result ( Wrong )

  ! Verify that each list item's predecessor's "next" component indexes

  ! that item, and the same for its successor mutatis mutandis.

    class(list_t), intent(in) :: List(:)

    character(*), intent(in), optional :: Message

    integer :: I, N, P

    do i = 1, size(list)

      p = list(i)%prev

      n = list(i)%next

      wrong = .false.

      if ( p /= 0 ) wrong = list(p)%next /= i

      if ( n /= 0 ) wrong = wrong .or. list(n)%prev /= i

      if ( wrong ) then

        if ( present(message) ) write ( unit, '(a)' ) trim(message)

        call dump_list_item ( list, i, prevNext=1 )

      end if

    end do

  end function Check_List



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20211210/8c1915d8/attachment.htm>