On Thu, 26 Apr 2018 14:19:51 +0200 Nicolas George <geo...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
