Re: [FFmpeg-devel] [PATCH 23/25] fftools/ffmpeg_filter: add filtergraph private data

[Anton Khirnov <anton@khirnov.net>]

Quoting Nicolas George (2023-04-24 14:13:45)
> Anton Khirnov (12023-04-24):
> > What exactly is less readable? One variable gets its scope reduced, that
> > is a win in my book.
> 
> Having to remember if a field is in structure x or structure y s a net
> loss that you do not see only because you just wrote the code and have
> everything freshly in mind.

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.

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.

> >			And obviously I'm not stopping there, other things
> > will be moved to this private struct in future patches,
> 
> Then move them into FilterGraph itself. If at some point later it makes
> sense to separate this structure to make the code clearer, we can do it
> at that time. If it happens, I predict the split will not be along the
> same “public”/“private” distinction you are trying to make right now.

Now that would be pure noise. I already know FilterGraph will have
private data, I intend to move more things into it in the very next
patchset.

> > Also note that exactly the same pattern is used in ffmpeg_demux,
> > ffmpeg_mux, and ffmpeg_enc (and soon in ffmpeg_dec).
> 
> If I had noticed it at the time, I would have objected the same way.

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?

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".