-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve support for method properties (name, etc.) #23
Comments
There are some problems with that though. For example the value of If we put these variable in the abstract class, then we'd need to set their values in some initialization step, which also would probably mean a |
Ok, got it. 2nd iteration: we take the logic currently used to deliver the order type :: properties
integer :: p
integer :: ncache
character(:), allocatable :: name
...
end type We add a get_properties method to type,abstract,public :: rk_class
...
procedure(properties_func), deferred :: get_properties
end type For each method, we define a properties function (replacing what is done today for order): pure module function rkbs32_properties(me) result(res)
implicit none
class(rkbs32_class), intent(in) :: me
type(properties) :: res
end function rkbs32_properties and update submodule(rklib_module) rklib_properties
implicit none
contains
module procedure rkbs32_properties
!! Returns the properties of the [[rkbs32]] method
res%p = 3
res%ncache = 1
res%name = "rkbs32: Bogacki-Shampine 3(2) method"
end procedure rkbs32_order
... I suppose this would work because it is just an extension/generalization of what is done currently. |
This is a good idea. I'm going to work on it. Actually, I'm working on a script to generate all this boilerplate code (interfaces, include files, etc.) automatically. I can add these to that. So we just specify the properties of the methods in a table and the code is autogenerated by a python script. |
added python script to generate all the files See #23
Addressed in #24. |
I think it would be helpful if the method classes included a character component storing the name of the method. Among other things, we could then run tests in a more programmatic manner.
Actually, pushing the idea one step further and combing it with #22, I was wondering if it would make sense to add the properties of a method as components of the corresponding concrete class:
I believe this would also avoid the need to have$N$ "method_order" procedures, whose sole purpose is to return
p
.The text was updated successfully, but these errors were encountered: