> So you annotate each C fn with a classname? Hmm, I'd have to mull that over.
> It might work for your purposes
> but I'm not sure it's such a great idea in general. Doesn't hurt, I guess,
> but I think I would be more inclined to
> put that kind of info in a separate layer. Separation of concerns - C is not
> OO, I think of it more in functional
> terms, fwiw.
Correct, C isn?t OO, but it?s in many ways the Iotivity C-SDK is exposing
objects as if they are. Ie when the first parameter is the object to perform
the operation against, it?s the same as if that method was on that object. It
think the example above is a reasonable interpretation of the C-SDK into an OO
object.
> Mapping to oo is fine but we also have non-OO (specifically functional)
> languages to think about.
You can do whatever you want for each language in the code generator. The crux
is we need to make sure the doc has enough information to allow each generator
to create what they need.
> in the case of iotivity just having doxygen would be a bigly improvement.
I don?t think anyone ever questions the need for better and more detailed doc ?
> the interface generation part sounds like a job for Swig,
actually.
I?ve yet to see a good product built with Swig. In my mind Swig?s goal is to
just make it work with very little effort. It?s goal isn?t to create something
that?s great, easy and intuitive to use.
/Morten
From: Gregg Reynolds<mailto:[email protected]>
Sent: Wednesday, January 11, 2017 1:19 PM
To: Morten Nielsen<mailto:mn at iter.dk>
Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at
lists.iotivity.org>; Thiago Macieira<mailto:thiago.macieira at intel.com>
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and
cbor encoder
On Jan 11, 2017 3:00 PM, "Morten Nielsen" <mn at iter.dk<mailto:mn at iter.dk>>
wrote:
...
For example you could change this C-SDK member:
/**
* This function gets the byte string from the payload.
*
* @param payload Pointer to the payload from which byte string needs to be
retrieved.
* @param name Name of the byte string.
* @param value Byte string and it's length.
*
* @note: Caller needs to invoke OCFree on value.bytes after it is finished
using the byte string.
*
* @return true on success, false upon failure.
*/
bool OCRepPayloadGetPropByteString(const OCRepPayload* payload, const char*
name, OCByteString* value);
to this:
/**
* This function gets the byte string from the payload.
*
* @param [in] payload Pointer to the payload from which byte string needs
to be retrieved.
* @param [in] name Name of the byte string.
* @param [out] value Byte string and it's length.
*
* @note: Caller needs to invoke OCFree on value.bytes after it is finished
using the byte string.
*
* @return true on success, false upon failure.
* \public \memberof OCRepPayload
So you annotate each C fn with a classname? Hmm, I'd have to mull that over.
It might work for your purposes but I'm not sure it's such a great idea in
general. Doesn't hurt, I guess, but I think I would be more inclined to put
that kind of info in a separate layer. Separation of concerns - C is not OO, I
think of it more in functional terms, fwiw.
Mapping to oo is fine but we also have non-OO (specifically functional)
languages to think about.
in the case of iotivity just having doxygen would be a bigly improvement.
g
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170111/f1bf9c58/attachment.html>
