add support for template/generic types
delaitre-manfrotto opened this issue · comments
Right now one can have a list<T>, set<T> or optional<T> but nothing else.
It would be really useful to be able to define user specified generic types!
Right now the only solution is to duplicate the djinni API for each types...
e.g. we have a generic property<T> type in C++, but we have to expose it as property_i32, property_float, property_foo, property_bar... in djinni which is really annoying
That is an interesting idea which needs some thought and investigation.
The existing templates (list/set/map/optional) have corresponding mappings in all target languages:
https://djinni.xlcpp.dev/djinni-generator/idl/#data-types
Other languages might not have an idea about user defined templates, so how should / could they be mapped?
According to wikipedia all the languages Djinni currently support has support for generic, and basically all the languages you might want to support right now also has support for them.
But this also brings the more generic question of: do you want to limit more advanced features to be implemented if not supported by one language? maybe the feature set a user can use can depends on what language he is interested in (e.g. I am not interest in python, so why should python limit what djinni can do if I am not going to target this language?)
A good example would be properties for example. I said we have a custom property type that we want to expose, but djinni could actually have support for properties built-in if we wanted to, as some languages provides such functionalities. But this is not the case for all languages by any means. Here you have 3 options:
- support properties in djinni, but implement it only for languages supporting it
- support properties in djinni, use language built-in feature if possible, otherwise provide custom property implementation for others
- don't support properties in djinni at all
I convert that issue into a discussion, since I do not see a possible definition of done in a reasonable time.
We do not have a clear picture of how we could implement that, and in how many concrete issues / tasks such a feature would result.
Therefore, as long as this is an idea, I think discussion is the right place to do brainstorming and collecting thoughts on that topic