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

Nicolas George 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
> 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.

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/20180426/2b8d9fab/attachment.sig>


More information about the ffmpeg-devel mailing list