add support for template/generic types

[delaitre-manfrotto]

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

[a4z]

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?

[delaitre-manfrotto]

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

[a4z]

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

[eakoli]

@delaitre-manfrotto Using the additions here #113, its possible to implement a matching generic container on the ObjC side.

template<typename T>
struct my_type<T> {...}

@interface my_objc_type<ObjectType>
...
@end

public class my_java_type<T> {
....
}

where using the type as so

my_record = record {
     value_one: my_type<i32>;
     value_two: my_type<string>;
}

would generate

@interface my_record : NSObject {
   @property (...) my_objc_type<NSNumber*>* value_one;
   @property (...) my_objc_type<NSString*>* value_two;
}

public class my_record {
    public final my_java_type<Integer> value_one;
    public final my_java_type<java.lang.String> value_one;
}

If you have the full example of what you have created for one or two of the property_XXX that you have implemented I can determine how much of whay your doing manually can be dried up with the changes in that PR.