-
Notifications
You must be signed in to change notification settings - Fork 17
Packaging without polymorphism #281
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
Comments
I'm unclear on to what extent this request overlaps with #87. |
@rouson , can you please take another look at #37 that proposes an "option to derive an inextensible type" in Fortran? You will notice one of the benefits of that proposal will be to make it easier to "package" related methods (and data) into public "class" i.e., a derived type without having to deal with polymorphism. #37 may not cover everything you have in mind and I believe #37 will be valuable on its own, but if you can give #37 a thought and share your feedback on it, it will be useful. |
@FortranFan thanks for pointing me to #37. I had not noticed it before and will read it shortly. |
@FortranFan I just clicked thumbs-up on #37. I agree that it would be one way to achieve the same ends as my proposal. |
Using a derived type
foo_t
in a modulefoo_m
automatically gives access to all of the type's public type-bound procedures:use foo_m, only : foo_t type(foo_t) foo call foo%bar
without the need to explicitly name the public type-bound procedures (e.g.,
bar
) in theuse
statement'sonly
clause. This can be very convenient in that it obviates the need to provide a potentially long list of procedures in theonly
clause. However, this capability is inextricably linked to polymorphism by the requirement that the passed-object dummy argument must be declared with the keywordclass
. It would be nice to have some sort of packaging mechanism that makes a collection of procedures accessible wherever a related type is accessible without also inherently enabling polymorphism, which obligates the programmer to perform runtime checks of the passed-object dummy argument's dynamic type in some situations in order to ensure type safety.The text was updated successfully, but these errors were encountered: