Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## cross-reference #33 +/- ##
===================================================
- Coverage 100.00% 96.52% -3.48%
===================================================
Files 7 10 +3
Lines 68 115 +47
Branches 0 4 +4
===================================================
+ Hits 68 111 +43
- Misses 0 3 +3
- Partials 0 1 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
znicholls
left a comment
There was a problem hiding this comment.
Nice - going in the right direction
| ! class(*), allocatable :: data_v(..) | ||
| ! MZ: assumed rank can only be dummy argument NOT type/class argument | ||
| ! Data i.e. the result (if no error occurs) | ||
| ! | ||
| ! Assumed rank array | ||
| ! (https://fortran-lang.discourse.group/t/assumed-rank-arrays/1049) | ||
| ! Technically a Fortran 2018 feature, | ||
| ! so maybe we need to update our file extensions. | ||
| ! If we can't use this, just comment this out | ||
| ! and leave each subclass of Result to set its data type | ||
| ! (e.g. ResultInteger will have `integer :: data`, | ||
| ! ResultDP1D will have `real(dp), dimension(:), allocatable :: data`) |
There was a problem hiding this comment.
| ! class(*), allocatable :: data_v(..) | |
| ! MZ: assumed rank can only be dummy argument NOT type/class argument | |
| ! Data i.e. the result (if no error occurs) | |
| ! | |
| ! Assumed rank array | |
| ! (https://fortran-lang.discourse.group/t/assumed-rank-arrays/1049) | |
| ! Technically a Fortran 2018 feature, | |
| ! so maybe we need to update our file extensions. | |
| ! If we can't use this, just comment this out | |
| ! and leave each subclass of Result to set its data type | |
| ! (e.g. ResultInteger will have `integer :: data`, | |
| ! ResultDP1D will have `real(dp), dimension(:), allocatable :: data`) | |
| ! Sub-classess hould have a `data` attribute | |
| ! We do not have that here, because Fortran does not have an `Any` type. |
|
|
||
| contains | ||
|
|
||
| subroutine clean_up(self) |
There was a problem hiding this comment.
Is clean_up the name to use for automatic deallocation ?
There was a problem hiding this comment.
No it is not. The automatic deallocation is done using the final :: my_procedure.
But for abstract types I've found a problem:
- Fortran requires that the dummy argument of a final procedure must be declared with the exact type, not the polymorphic class;
- But an abstract type cannot be instantiated.
So final requires an exact type, but abstract types forbid exact-type dummies and that's a conflict I could not resolve.
The solution might be to have a clean_up procedure in the abstract type that gets called in the final routine of the child type to then make error_v to deallocate. I do not know if this makes sense.
| ! procedure, public:: build | ||
| ! TODO: Think about whether build should be on the abstract class | ||
| ! or just on each concrete implementation |
There was a problem hiding this comment.
| ! procedure, public:: build | |
| ! TODO: Think about whether build should be on the abstract class | |
| ! or just on each concrete implementation | |
| ! Sub-classes should implement a build method too. | |
| ! As above, we can't implement this here | |
| ! because Fortran doesn't have an `Any` type | |
| ! (which is what we would need for `data`) |
| !! | ||
| !! Holds either an integer value or an error. | ||
|
|
||
| integer, allocatable :: data_v(:) |
There was a problem hiding this comment.
| integer, allocatable :: data_v(:) | |
| integer :: data_v | |
| ! or | |
| integer, allocatable :: data_v |
To start, let's just do an int, rather than a 1D array of int
There was a problem hiding this comment.
I did an array because one has to take care of the allocation. But ok, no problem in doing scalars first.
|
|
||
| end function constructor | ||
|
|
||
| subroutine build(self, data_v_in, error_v_in) |
There was a problem hiding this comment.
| subroutine build(self, data_v_in, error_v_in) | |
| function build(self, data_v_in) result(error_v_in) | |
| ! or would the following work | |
| function build(self, data_v_in) result(result_v) | |
| ! and we return a `ResultNone` type |
| ! Hopefully can leave without docstring (like Python) | ||
|
|
||
| if (allocated(self % data_v)) deallocate (self % data_v) | ||
| if (allocated(self % error_v)) call self % clean_up() |
There was a problem hiding this comment.
| if (allocated(self % error_v)) call self % clean_up() | |
| call self % clean_up() |
Add first test of raising error on python side
Description
Providing classes to handle 1D integer arrays of results.
Checklist
Please confirm that this pull request has done the following:
changelog/