Strongly typed dictionaries
LecrisUT opened this issue · comments
Is it possible to do, e.g. what are minimum changes need to extect dictionary_t to make it strongly typed and give a compilation error if the wrong constructor, assign, contains interfaces are used.
What do you mean? If you want another entry, simply overload the operators you wish to use, and then it will work. All exposed methods are overloaded for this reason.
I mean the equivalent in C++ of:
#include <map>
#include <string>
std::map<std::string,int> strongly_typed_dict{};
strongly_typed_dict["key"] = 1;
// strongly_typed_dict[1.3] = "string" // Does not compile because wrong key type
// strongly_typed_dict.contains(3) // Does not compile because wrong key typeMy understanding of fortran's generic is that you can add interfaces with the same name, but you cannot delete them. I am thinking if it can be implemented as dictionary_base_t%contains_impl where contains_impl is a private method, than dictionary_t has the necessary public interfaces dictionary_t%contains with generic interface. Then if we want to make a strongly typed dictionary we extend dictionary_base_t and only implement contains for the exact type of the key.
I see.
No, I don't have plans for this. This is quite easily done with a direct type in the container, in fdict you should
change the type(variable_t) with whatever you only want to retain.
Please do remember that this project is for basic f90 practices, if you want 2003 of generic data-types, use type(*) instead, but I think that is beyond the scope of fdict.
I also don't see a big benefit. Yeah, you'll drop out some of the complicated discovery of data-type, but if all you want is a simple hash-table with a single data-type allowed, then it is quite simple to implement.
Please note that this implementation does not allow any data-type to be contained by default, i.e. you need to explicitly add an interface for things that are not implemented.
Hmm, that's a pity though. The issue is that fortran does not have an std library nor any consistency between each project. So everyone invents square wheels. Having a reference library and interface would be beneficial in that aspect, especially since there would be more developers contributing and fixing each others bugs than if one just develops for themselves.
I think you are not aware of https://github.com/fortran-lang/stdlib then?
While I do agree, my code here was primarily targeted legacy codes which did not use the latest and greatest fortran features.
Now it may in some regards be somewhat obsolete, but I do think that it has its merits, performance wise. E.g. I would expect select type(*) to be a bit slower due to the class overhead.
I do agree about the reference library, but people have tried this for many years. AFAIK boost was only successful because of big efforts at the organizational level. Creating a library is easy, but if the community does not support it it will crumble.
It is not that people don't want to, but it takes a big effort to rely on other peoples code.
I do believe that fortran-lang stdlib is the way to go, there are many things happening there, and people contribute a lot. This will surely help fortran codes!
I'll close, thanks for the issue.