[FFmpeg-devel] [GSoC] FFserver further development direction
george at nsup.org
Thu Apr 26 15:19:51 EEST 2018
Josh de Kock (2018-04-26):
> >>Generally, adding more things to public API is a bad move
> What I mean by this is making private fields public is generally a bad move.
> They were initially made private for a reason, and if you suddenly need to
> modify them outside then you must ask: What does this new code do
> differently to all the other code which makes it require a private field?
> It's a matter of consistency, if some new code could be written without
> requiring a private field to become public then this is better.
> It's also a matter of complexity, the API is less complex if there are less
> public field. If it wasn't better then please submit a patch which makes all
> private fields public. Of course, this doesn't apply to everything sometimes
> there are genuine reasons for new API fields to be added but *generally* a
> smaller API leads to a better experience. I did say that in this case I was
I think the statement you justified here is:
"Generally, adding more things to public API *without need* is a bad
I agree with that statement. But I also agree with the statement:
Generally, adding more thing to public API when needed is a good move.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-devel