On date Tuesday 2024-07-02 11:58:09 +0800, Zhao Zhili wrote: > > > 在 2024年7月2日，上午6:33，Stefano Sabatini <stefa...@gmail.com> 写道： > > > > On date Sunday 2024-06-16 18:08:29 +0100, Andrew Sayers wrote: > >> The old name could be misread as the opposite of "AV_OPT_FLAG_READONLY" - > >> some things can be set at runtime, others are read-only. Clarify that > >> this refers to options that can be set after the struct is initialized. >
> Let’s not bother the user again and again for little benefit. Add > doc is fine, please don’t rename the flag. The point is that name is the documentation, having a better flag name guarantees simpler/better use of the API, as opposed to a once-time mechanical name change for a flag which is probably never used in external applications code. Aslo, by following this rule, we should never rename flags for "little benefit", sticking to misnamed constants (as this is the case) which require much more effort to double check the API (since the name was misleading, you need to double check with the API). If you think in terms of developer time, it is easy to measure the time required to check and replace the code (a few minutes?) while it is much harder to assess the overall time spent checking/writing/validating the code due to bad naming, but my suspect is that even for a trivial change like this one, it is a much bigger time that you are saving to the user. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
