Handling of 'incorrect' definition of djinni interface - +o +j vs +c

[martin00001313]

Based on current djinni implementation, if there is a djini interface with +j +o specification and implementation in C++ layer, the ios layer use leads to 'bad_cast' execution. Specifically:

----- in Djinni layer
it1 = interface +o +j { ... } # marked as implementable in java/ios layer

manager = interface +c {
get_instance_it1(): it1;
}

---implemented in c++
class itImpl : public It1 {...}

std::shared_ptr<It1> Manager::GetInstanceIt1() { return std::make_shared<It1>(); }

---in ios layer

let x = Manager::getInstanceIt1(); // this will lead to std::bad_cast as dynamic cast to objs proxy is not valid. C++ -> djinni dynamic cast should be applied instead

----End

Is this something expected/defined by Djinni? Or it can be updated to provide more 'informative' behavior, like a specific error message or if applicable(need to dive deep) djinni processing validation with compilation error?

P.S. Btw, I know the client should make sure to not make such mistakes.
Thanks.

[artwyman]

Sounds like you understand that's not supposed to work as-is? Your interface should be marked +c if it's going to be implemented in C++. Note that you can mark an interface as +o +j +c if you want to be able to implement it anywhere.

Are you describing a runtime error, or a compile-time error? I'd expect the missing code to cause failures at compile time, not get far enough to throw a bad_cast. I agree that a runtime failure would be unfortunate, though maybe there's some dynamism somewhere which is causing it. I'd need to know more about the source (file/line) of the error to comment further. (But note that I'm a retired maintainer of the Dropbox Djinni repo from which this repo is forked, so there could have been changes, and I'm not well set up to do active development.)

Informative compile-time errors at that layer would be great, but definitely challenging to accomplish. At that point you're running the compiler, not Djinni, so it's hard for Djinni to customize the behavior. The intent of the +o +j +c tags is to let Djinni generate less code for unnecessary cases, so it's hard for it to control error messages for code which is missing.

[martin00001313]

Right, based on the latest dropbox fork of djinni, if the interface is defined with +j +o, but implemented in C++, the call to get the instance from C++ layer(through std::shared_ptr) is leading to std::bad_cast exception. The reason of that:

The base class/interface being generated in C++ by djinni is BaseT

In C++ layer is implemented the interface, like: BaseTImpl : public BaseT

For C++ to ObjC translation, djinni does dynamic_cast<ObjcProxy&>(*cpp), where:
ObjcProxy : public BaseT, public ObjcProxyBase and cpp is type of const std::shared_ptr<MyT>& cpp

As ObjcProxy is not a parent of BaseTImpl, the casting leads to std::bad_cast exp.

P.S. Thank you for providing the Djinni interface and functional. It has big contribution of cross-platform development on C++!

[artwyman]

Interesting. I can see why that cast is necessary to find an object in the proxy cache, and why it would fail in this case. I'd expect that elsewhere in the glue code there would be some other code which needs to create new CppProxy object of the specific proxy type corresponding to your class (if the lookup in the proxy cache failed). Such a proxy class would not be generated at all, which would fail to compile.

On a hunch, is it possible that you didn't clean up generated files between test cases, and you had an earlier version marked +c which generated the proxy class file? If you've ended up mixing files from different generator runs it could certainly lead to unexpected results. Try deleting your generated output directory, and regenerating to see if the behavior is the same.

If that hunch doesn't pan out, though, I'm not in a good situation to debug this deeply myself at the moment (I'm leaving for a trip tomorrow, and haven't done development on this community-run repo before). But I agree with the basic philosophy that it would be best if configuration errors were flagged at compile time rather than runtime.

[martin00001313]

No, the problem is reproducible for clean build and on different environments.

However, this is not smth. blocker as with +c config it works fine. It may be 'follow up' for currently supported djinni forks.
Will try to follow up with a possible improvement as have a plan to switch currently supported one of the djinni forks.

Thanks!

[artwyman]

This one is supported, by a community, just not by me personally. I'm just here to be helpful with historical knowledge.
An actual maintainer might have a comment on this discussion later.
I maintained the original version at Dropbox, but archived it when I left there a few years ago.

[a4z]

And your help is super appreciated, @artwyman . Thank you so much!