[FFmpeg-devel] [PATCH v2 1/3] libavutil/imgutils: add utility to get plane sizes
Alexander Strasser
eclipse7 at gmx.net
Fri Jul 24 00:24:28 EEST 2020
On 2020-07-22 11:56 +0200, Nicolas George wrote:
> James Almer (12020-07-20):
> > No, i'll push v3 soon if my argumentation below was not enough to
> > convince Nicolas or Michael. My intention is to use ints for the new
> > function, not to postpone committing it in any form indefinitely.
>
> Sorry, I missed you mail earlier, I only read your arguments nowish.
>
> You are emphasizing that the "future-proof" argument is rather weak,
> which I was already aware. And you are underplaying the fact that it
> belongs to a trend to always delay necessary changes.
>
> Anyway, even if all the arguments for using the proper types are all
> very weak, there are several, and together I am still convinced they
> exceed "consistency" easily.
>
> consistently good > inconsistently good and bad > consistently bad
> ^
> |
> this is the discussion we are having
From what I have read so far this is not a simple black and white
decision.
I think it's a discussion about coarseness of change. Improving
everything at once will likely never happen in a good way. But
still there are more step sizes in between.
Here is a excerpt of what Michael wrote before:
> If not (as in its more mess than if its done later in some other way)
> then we should not try to do this now
>
> The idea is just to take a step towards how these functions/API should look
> ideally. Its not to make some inconvenient mess
Changing at a per function level is the finest possible way of
API adjustment. Changing a group of functions would be the next
coarser way to adjust the API, and that's what I think James
opts for.
I personally would be OK with that strategy. It emphasizes on
the value of API users. As an API user I would find it annoying
to have inconsistencies at a per function level, even in the
same group of functions that are tied together by name and
by header.
In the long term, I believe we should focus on even more
consistency among groups of functions and libraries and
even cut down on the number of API functions needed.
Alexander
More information about the ffmpeg-devel
mailing list