[FFmpeg-devel] [GSoC] FFserver further development direction

wm4 nfxjfg at googlemail.com
Thu Apr 26 15:27:47 EEST 2018


On Thu, 26 Apr 2018 14:19:51 +0200
Nicolas George <george at nsup.org> wrote:

> 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
> > unsure.  
> 
> I think the statement you justified here is:
> 
> "Generally, adding more things to public API *without need* is a bad
> move."
> 
> 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.

All public API was added because someone felt a need for it at one time
in the past.


More information about the ffmpeg-devel mailing list