Design of library_interface.F90

[LecrisUT]

I would like to suggest that module/submodule interface should be used for the api library. Having functions like get_fortran_stderr is not helpful for the user, and it otherwise complicates the navigation of the interface to find the relevant interface the user would need. Splitting these and making them private to the submodule would simplify the interface.

To properly test if the import works, #444 would be helpful, since that would give a clean environment as if the package was installed on the system. I have implemented something similar in spglib and that could be adapted here as well.

Also, is there a reason for keeping the functions like set_u_matrix as global functions instead of class methods?

[JeromeCCP9]

Hi Cristian!

These are design questions, yes.

The rationale behind get_fortran_stderr is for use by python, where it is necessary to have a public function (of course this function is not needed from fortran).

Concerning the encapsulation, this design choice was part of our remit when we were given the library task: that the interface should consist of simple global functions. Whether this is best is a tricky discussion, but we feel that the simple function interface also makes calling the library from other languages much easier.

We touched on this with the other developers and our design was essentially accepted, but ultimately it is a community decision & others may wish to comment.

Does this more or less answer your question?

Jerome, Barry

[LecrisUT]

The rationale behind get_fortran_stderr is for use by python, where it is necessary to have a public function (of course this function is not needed from fortran).

I am not sure I am getting this. Python also has access to stderr, and since this is just an integer, it doesn't make a difference if it is specified by python or fortran. If it was lib_common_type%err_log that would make more sense, because that would indicate where all error logs would need to go.

Whether this is best is a tricky discussion, but we feel that the simple function interface also makes calling the library from other languages much easier.

You can have both of course. A cleaner object oriented interface for use across fortran projects, and global function interface for linking to other languages. This is a common C++/C design. Also in order to make calling the language across languages, it should also have bind(C) and equivalents.