[FFmpeg-devel] Public and private structs and fields (was: lavc: add new API for iterating codecs) and codec parsers

Nicolas George george at nsup.org
Sun Dec 24 17:54:33 EET 2017


I fully agree with the point you are making, but there is an argument
you are invoking that I do not agree with at all.

James Almer (2017-12-24):
> So yes, it's literally a side effect of us putting internal fields in
> public headers, an awful practice that no one else does

No one else, except glibc, OpenBSD, Gtk+ (until the Gnome guys took
over), which are just the examples that come to mind immediately.

the need for having internal fields in public headers is a consequence
of the design of the C language. There are other languages that offer
better options, but they all have also drawbacks in other area, and I am
pretty sure the vast majority here would rightly be against
reimplementing FFmpeg as a C++ or Rust project.

There are also other options within the C language, but they all have
huge drawbacks.

So when you are saying that it is an awful practice, it is the same as
with Churchill's quote about democracy being the worst form of
government: it is an awful practice, but all other practices to achieve
the same result are even more awful.

There may be a better solution that we have not thought of yet. But if
you propose something, please stay open about the drawbacks that you may
not have seen or may not affect your work flow.

> People will always misuse the API when they can, and it should never be
> a reason to condition development.

I fully agree with that, but beware, I will keep you to it.

It relates directly to the point above: if people are not able to read
"this field is private, do not touch it", that does not mean we should
make it public. But it does not mean that we should make complex efforts
to hide them.

> Merry Christmas :)

I wonder what I should be merrier about: twenty centuries of dogmatic
brainwashing, or the unbounded consumer society leading to a global
ecologic catastrophe.

Happy days-getting-longer to you all!

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171224/a6a4b3ad/attachment.sig>


More information about the ffmpeg-devel mailing list