Question about a library C API

[Francis Moreau]

Hello,

I have to use a library which has an API that I find a bit weird for
the C language, so I'd like to get some feedbacks to know if it's a
good API design for C or it's just a bad practice.

Basically this API is an object oriented API.

To allocate an object I have to use for example:

o = alloc_object();

Once I have a reference on that object, I have directly access to its
internal data structure. So to call its methods I can do this:

o->m1();

And this is what I find weird. I would do instead:

m1(o);

which is more natural when doing C (probably because all very used
lib, like the libc, pthread... don't do this) and has the advantage to
not expose the internal data of 'o'.

Could anybody tell me if there is one good reason to do so ?

Thanks

 

[Chris Dollin]

I have to use a library which has an API that I find a bit weird for
the C language, so I'd like to get some feedbacks to know if it's a
good API design for C or it's just a bad practice.

Basically this API is an object oriented API.

To allocate an object I have to use for example:

o = alloc_object();

Once I have a reference on that object, I have directly access to its
internal data structure. So to call its methods I can do this:

o->m1();

And this is what I find weird. I would do instead:

m1(o);

which is more natural when doing C (probably because all very used
lib, like the libc, pthread... don't do this) and has the advantage to
not expose the internal data of 'o'.

Could anybody tell me if there is one good reason to do so ?

Different objects of the same (super)type can have different
implementations of m1. [eg: streams, where FILE*-based streams
and from-memory type streams are both streams.]

m1 is not a global name, so different types don't tread on each
others method names. [There are lots of different things one might
mean by `append`, `next`, `parse`, `save`, &co.]

[These advantages should not be taken as an endorsement of the
API as presented.]

 

[Francis Moreau]

I have to use a library which has an API that I find a bit weird for
the C language, so I'd like to get some feedbacks to know if it's a
good API design for C or it's just a bad practice.

Basically this API is an object oriented API.

To allocate an object I have to use for example:

o = alloc_object();

Once I have a reference on that object, I have directly access to its
internal data structure. So to call its methods I can do this:

And this is what I find weird. I would do instead:

which is more natural when doing C (probably because all very used
lib, like the libc, pthread... don't do this) and has the advantage to
not expose the internal data of 'o'.

Could anybody tell me if there is one good reason to do so ?

Different objects of the same (super)type can have different
implementations of m1. [eg: streams, where FILE*-based streams
and from-memory type streams are both streams.]

sure but you get the same with:

void m1(struct object *o)
{
o->m1(o);
}

depending on what 'o' really is, m1 can be different.

m1 is not a global name, so different types don't tread on each
others method names. [There are lots of different things one might
mean by `append`, `next`, `parse`, `save`, &co.]

well, if I have to design a lib API, I would never name a function of
that lib: 'append', that would be silly...

thanks

 

[Chris Dollin]

well, if I have to design a lib API, I would never name a function of
that lib: 'append', that would be silly...

No matter what name you pick [1], some other library will have an
equally good claim on the name [2]. `append`, etc, are just convenient
examples.

[1] Namespace prefixing help, but just pushes the problem up one
layer. Long names help, but push the code toward unreadability.

[2] There are probably too few concepts being librified to spread
out the names.

 

[Francis Moreau]

well, if I have to design a lib API, I would never name a function of
that lib: 'append', that would be silly...

No matter what name you pick [1], some other library will have an
equally good claim on the name [2]. `append`, etc, are just convenient
examples.

If you really insist on that point, I think the problem is still there
since the object needs to be allocated by a global function...

I agree this issue is less frequent though but as I said, I think it's
not real issue IMHO.