From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id D3D3C45BD3 for ; Mon, 24 Apr 2023 19:17:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0B91F68BEC5; Mon, 24 Apr 2023 22:17:46 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2B12E68B8AC for ; Mon, 24 Apr 2023 22:17:39 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id A22462404EE for ; Mon, 24 Apr 2023 21:17:38 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id e-mnyh1OWX35 for ; Mon, 24 Apr 2023 21:17:37 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id AC7E82404EC for ; Mon, 24 Apr 2023 21:17:37 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 8CF7A1601B2; Mon, 24 Apr 2023 21:17:37 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20230419195243.2974-1-anton@khirnov.net> <20230419195243.2974-23-anton@khirnov.net> <168233503763.3843.15441944598302423310@lain.khirnov.net> <168233747463.3843.6914979374280115185@lain.khirnov.net> <168233804222.3843.2176038618353077915@lain.khirnov.net> <168233943029.9711.17568532350489119659@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Mon, 24 Apr 2023 21:17:37 +0200 Message-ID: <168236385755.3843.9294759004440412931@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 23/25] fftools/ffmpeg_filter: add filtergraph private data X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Nicolas George (2023-04-24 20:31:49) > 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. I have no idea what you mean by this. > > 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. > true > fact You keep using these words. I don't think they mean what you think they mean. The only fact here is that the quoted paragraph is YOUR PERSONAL OPINION, which ZERO other developers expressed support for. On the other hand, the approach under discussion has explicit support from multiple highly active developers. > > 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. You are too late, many such changes have already been pushed in the last several years. Nobody except you opposes them and the likelihood of reversing them is extremely low. This whole thread is a pointless waste of time that could be spend doing something actually useful. -- 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".