Mapping an enum inside a struct in .djinni file

[SanaElshazly]

struct MyStruct
{
    enum MyEnum {
             option1,
             option2
        };

        static std::string toString(MyEnum const & m){}
};

I'm trying to map this in the .djinni file to generate the code in objective c, but having some issues as I don't get it on how I should map this. Should I write the whole enum as a standalone and not inside the struct as it is in the cpp file? Is the following mapping in the .djinni file is correct?

MyEnum = enum {
        option1;
        option2;

}

MyStruct = record {
   m: MyEnum;
} 

MyStructInterface =
interface +c {
    static toString(m: MyEnum): string;
}

[artwyman]

Yes, the enum needs to be independent. Djinni doesn't support nested types.

Also, it sounds like you're trying to generate an interface to match existing C++ code, which isn't the intent of Djinni. Djinni generates new interfaces in all languages from the IDL. It's not intended to perfectly replicate any pre-existing C++ interface. You should start with the IDL, then implement or use the interface it generates in all languages.

[SanaElshazly]

It looks like I misunderstood the usage of Djinni, I wanted to generate objective c wrappers for a pre-existing C++ code so I can use it inside my objective c project. Djini mainly allow to generate pre-defined interfaces that exist in the IDL file into several languages if I understood correctly, right? I wanted to get some clarifications on the part of "You should start with the IDL, then implement or use the interface it generates in all languages.", I mean what interface do I implement or use? is it the generated one? or a C++ interface that I implement according to the IDL? and does that mean that the generated interfaces can be implemented by myself rather than generating them? and if yes, then why do I use the IDL? I mean what is the main purpose for writing the IDL files? Although I am confused; as the IDL will be only for the interfaces; what about the rest of the code? I mean where the APIs implementation will be defined? do I implement the APIs according to the generated interfaces? because, I might have the API implementation encapsulated in C++ code/library, and called from the generated interfaces from Djini.

[finalpatch]

Hi Sana, Djinni defines the interface between native code and platform code (java/objc). Due to the inherent difference between the languages, Djinni can only support a common subset of features.

The normal use case for Djinni is you design the interface between native code and platform first, then implement these interfaces (protocols or abstract classes) in native and platform code. But if you already have some code, then it's obvious they are not derived from Djinni defined interfaces, so you can't directly expose them to the other side (unlike tools such as SWIG).

If you want to expose existing code, you'll need to create a Djinni interface, and wrap your existing code behind the Djinni interface.

[artwyman]

You should check out the videos and tutorials linked at the end of the README.md file, which may help understand the intended usage model. Djinni generates abstract classes (with pure virtual functions), and you need to provide the implementation. You could have that implementation forward to your pre-existing classes. The main value of what Djinni generates is the code that allows the new interface to be called across languages. All of the marshalling code to do so is generated by Djinni.