Support for abstract interfaces about ford HOT 8 CLOSED

I think I should rephrase my question: I see in class FortranInterface(FortranContainer), in sourceform.py, that this class already includes

 self.abstract = bool(line.group(1))

My question is whether this is already a complete implementation or only a preliminary placeholder.

I think that abstract interfaces are much more like types rather than overloaded interfaces, and maybe it would make sense to treat them separately providing a list, and having them processed in two templates like

aint_list.html aint_page.html

Marco

from ford.

Okay, two things here really. As it stands, FORD is supposed to be able to process abstract interfaces. I'll have to take a look at what's going wrong there. As I've never used abstract interfaces in any of my own programs I may have forgotten to test that feature.

The other issue is how to display abstract interfaces. I take your point that they are more like a type than a normal interface. At some point (no guarantees as to when) I'll add the ability to handle them a bit differently from other interfaces. I'll certainly make a list of abstract interfaces, although I'm not sure that I'll need a whole new aint_page.html template.

from ford.

Okay, I found the bug which was causing FORD to crash. It was a silly little mistake on my part that was easy enough to fix. I'll push the changes up to Github and create a new patch-level release on PyPI.

from ford.

Very nice, thanks! This indeed suites my needs; while looking at it anyway I add a small nitpicking observation.

The point is that maybe handling the "abstract interface" block as such is a suboptimal solution compared to handling each one of the interface-bodies separately. Here is an example:

module m

 implicit none
 public :: i_s
 private :: i_f1, i_f2

 abstract interface
  subroutine i_s(x)
  !! Define the abstract interface for all the functions used in this
  !! program.
   integer, intent(inout) :: x
  end subroutine i_s

  !> Another interface for all the functions
  pure function i_f1(x) result(y)
   integer, intent(in) :: x
   real :: y
  end function i_f1
 end interface

 abstract interface
  !> Similar to `i_f1`, buth in a separate interface block
  pure function i_f2(x) result(y)
   integer, intent(in) :: x
   real :: y
  end function i_f2
 end interface

end module m

Here, ford lists i_f1 among the public entities of the module, since it happens to appear in the same abstract interface block as i_s. However, i_f1 is private, and the abstract interface is not private nor public. i_f2, which is exactly like i_f1, is treated correctly because it is placed in a different abstract interface block.

from ford.

I see what you mean. At some point I'll fix that. However, it might be several months. I really need to be devoting more time to my thesis, so for the next while I'll only be working on FORD to fix any bugs which people identify.

from ford.

Sure, good luck four your thesis!

Maybe if I have time I will try to put together something and make a pull request, just in case/when/if you will have time to consider it.

Marco

from ford.

I've reworked how interfaces are handled and I think you will now find abstract interfaces behave much more in line with how you'd like. Non-abstract interfaces are handled better now, too. I have only done some simple tests, so if you come across any bugs, let me know. You can find these improvements in the GitHub repository; they aren't on PyPI yet but should be within a day or two.

from ford.

These changes are now available on PyPI.

from ford.