On Mon, Apr 24, 2023 at 8:37 PM James Almer <jamr...@gmail.com> wrote:
> On 4/24/2023 3:33 PM, Paul B Mahol wrote: > > On Mon, Apr 24, 2023 at 8:32 PM Nicolas George <geo...@nsup.org> wrote: > > > >> Anton Khirnov (12023-04-24): > >>> So when I wanted to make changes to libavfilter recently, you claimed > >>> your familiarity with the code makes you more qualified to judge > >>> readability. Now my familiarity with the code makes me LESS qualified. > >>> Curious. > >> > >> There is a difference between long-term knowledge of a large part of the > >> code and a short-term acquaintance with a limited slice of the code, I > >> hope you realize. > >> > >>> We've also been moving private state to private data for many years now > >>> and none of your conjectured concerns materialized, to the contrary > code > >>> became easier to maintain. > >> > >> Untrue. For example, every instance of FFFormatContext in the code gives > >> places where the code has become that much more annoying to maintain. > >> Maybe the same code has become more maintainable at the same time due to > >> other changes, but the fact remains that these changes make it harder to > >> work on the code. > >> > >>> Now that would be pure noise. > >> > >> The only noise here is all the fgp_from_fg() you want to liter over the > >> code and the extra variables it requires. > >> > >>> I have no idea what are you even objecting to. What is even > >>> controversial about not exposing state that does not need to be > exposed? > >> > >> I have explained time and again: I oppose to any change that requires us > >> to remember or check which structure a given field belongs to when it is > >> not already obvious by its semantic. > >> > >> And again, there is nothing exposed to hide here. > >> > > > > Why should anybody here listen to your entries here? > > When was last time you contributed anything marginally useful? > > Lets limit things to technical arguments, please. > Nicolas want one monumental structure like old AVCodecContext and still current MPV structure. There is nothing technical in this discussion, from start, at all. > _______________________________________________ > 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". > _______________________________________________ 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".
