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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
