From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 5E26C1FF15E for ; Fri, 26 Jul 2024 14:45:38 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 109691E2A1; Fri, 26 Jul 2024 14:45:38 +0200 (CEST) Message-ID: Date: Fri, 26 Jul 2024 14:45:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Max Carrara , Proxmox VE development discussion References: <20240723095624.53621-1-f.ebner@proxmox.com> <20240723095624.53621-11-f.ebner@proxmox.com> <74a748f3-f7ff-4de5-aa1d-3378ae22c642@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [RFC storage 10/23] plugin: introduce new_backup_provider() method X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 26.07.24 um 14:02 schrieb Max Carrara: > On Fri Jul 26, 2024 at 11:52 AM CEST, Fiona Ebner wrote: >> Am 25.07.24 um 17:32 schrieb Max Carrara: >>> On Thu Jul 25, 2024 at 3:11 PM CEST, Fiona Ebner wrote: >> >> I don't quite get your point about not needing to update the call sites. >> If you change the structure of the passed-in hash you still need to do that. > > Pardon me, I was a bit imprecise there. You're completely right that the > passed hash has to be changed as well, of course. > > What I meant in particular was that because the signature (most likely) > won't change, we won't have to take special care to update the > individual arguments that are passed to a method when e.g. a parameter > is deprecated (or removed) or added. > > For example, optional arguments are often just left out (because that's > possible in Perl), so if we introduced another parameter ... > > * after the optional one, we'd have to pass something like `0` or > `undef` for the optional one first before passing the new one: > > # before > $plugin->foo($first, $second); > > # after > $plugin->foo($first, $second, undef, $new); > > * before the optional one, we'd have to make sure the order of arguments > is correct: > > # before > $plugin->foo($first, $second, 1); > > # after > $plugin->foo($first, $second, $new, 1); > > If we were to use a hash representing the parameters instead, the cases > would look like this respectively: > > $plugin->foo({ first => $first, second => $second, new => $new }); > > $plugin->foo({ first => $first, second => $second, optional => 1, new = $new }); > > More examples of that pattern would be `PVE::Tools::run_command` and > `PVE::RADOS::mon_command`. > > These changes can (and IMO should) still be guarded by an API age + > version mechanism, it's just that the *surrounding maintenance work* > becomes easier IMO, even if the initial cost for us and for implementors > is a bit higher. > > Of course, this is all a suggestion and I really don't want to seem like > I'm telling you what to do here! If you decide not to have a parameter > hash etc. then that's also completely fine by me, of course. :) > Okay, I see what you mean. I agree that having a hash for optional arguments is cleaner API-wise, but I do think fixed arguments (e.g. vmid and drive ID for VM backup will always be present) should go directly into the signature, not into a hash. I'll probably go with something like what I wrote before about having mechanism-agnostic signatures, one for VMs and one for containers. > > Also, thanks for going through this discussion here with me - even if > you choose to not incorporate my suggestions, I'm glad we have these > little exchanges, because they periodically update my perspective(s) on > Perl code as well :P > No worries, your feedback is very welcome :) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel