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 _______________________________________________ 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".
