This idea might be valuable or not, but in my day-to-day work we also have a C-SDK, and all its public methods are heavily documented and tagged.
We then use a combination of Doxygen and Python scripts to auto-generate higher-level OO classes for use by Objective C, Android/Java, .NET and QT/C++. This has worked really well for us across all the platforms once these scripts were solidified. It ensures all platforms have the same API, but the code-generator can adapt and tweak the APIs to make them feel/look more native to the platform. This was naturally a big investment setting up, but it has paid itself back many times over since. It also means adding another language/platform was very easy, as it was mainly just a matter of updating the code-generator. We also don?t even have to worry about the higher-level classes getting out of sync with the C-SDK. /Morten From: Gregg Reynolds<mailto:[email protected]> Sent: Wednesday, January 11, 2017 11:56 AM To: Thiago Macieira<mailto:thiago.macieira at intel.com> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Integer representation in OCRepresentation, OCRepPayload and cbor encoder On Jan 11, 2017 1:52 PM, "Gregg Reynolds" <dev at mobileink.com<mailto:dev at mobileink.com>> wrote: On Jan 11, 2017 1:46 PM, "Thiago Macieira" <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote: ... We should have a unified API in one language only -- I understand Microsoft's preference would be for a C API. +1 and for other languages (esp. oo languages), I'd like to see a single abstract api, so we don't end up with a different model for every language. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170111/9733b3dc/attachment.html>
