From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Aaron Lauterer <a.lauterer@proxmox.com>
Subject: Re: [pve-devel] [PATCH common v5 1/7] tools: add check_list_empty function
Date: Mon, 11 Nov 2024 19:19:34 +0100 [thread overview]
Message-ID: <891a10ee-21f2-4c22-8313-0157289bd6a8@proxmox.com> (raw)
In-Reply-To: <20241002131157.227292-2-a.lauterer@proxmox.com>
The subject still talks about the old name from v4, but..
Am 02.10.24 um 15:11 schrieb Aaron Lauterer:
> In some situations we don't want a total empty list. I opted for a
> dedicated function instead of integrating it as error in the
> `split_list` function. It is used in many places and the potential
> fallout from unintended behavior changes is too big.
>
> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
> ---
> changes since:
> v4: rename to `list_is_empty` and switch the return values
> v3: none
> v2: newly added
>
> src/PVE/Tools.pm | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/PVE/Tools.pm b/src/PVE/Tools.pm
> index bd305bd..36ffb05 100644
> --- a/src/PVE/Tools.pm
> +++ b/src/PVE/Tools.pm
> @@ -718,6 +718,14 @@ sub split_list {
> return @data;
> }
>
> +sub list_is_empty {
> + my ($list) = @_;
> + if (scalar(PVE::Tools::split_list($list)) < 1) {
(You're already in the PVE::Tools module, so this could call split_list directly)
> + return 1;
> + }
> + return 0;
... this saves the call site a not really much, i.e. it would one allow to
write something like:
if (scalar(PVE::Tools::split_list($list)) == 0) {
# ...
}
if (PVE::Tools::list_is_empty($list))) {
# ...
}
And don't get me wrong, having a dedicated helper for such things that then
semantically encodes what's checked for in the method name can be fine, but
PVE::Tools is already very bloated, and it doesn't seem like we already require
this pattern often, or did you found other sites where this could be used?
Once pve-common gets split up, and we got some more specific and smaller module
dedicated to such stuff it might be fine to add this helper there, but for now
I'd avoid adding this as long as there are not many (existing) use cases.
I could fix patch 6/7 up on applying if nothing else pops up to avoid that
you need to send a v6 just for this.
> +}
> +
> sub trim {
> my $txt = shift;
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2024-11-11 18:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-02 13:11 [pve-devel] [PATCH common, widget-toolkit, manager v5 0/7] fix #3893: make bridge vids configurable Aaron Lauterer
2024-10-02 13:11 ` [pve-devel] [PATCH common v5 1/7] tools: add check_list_empty function Aaron Lauterer
2024-11-11 18:19 ` Thomas Lamprecht [this message]
2024-10-02 13:11 ` [pve-devel] [PATCH common v5 2/7] inotify: interfaces: check if bridge_vids is truthy instead of defined Aaron Lauterer
2024-11-11 18:23 ` [pve-devel] applied: " Thomas Lamprecht
2024-10-02 13:11 ` [pve-devel] [PATCH common v5 3/7] fix #3893: network: add vlan id and range parameter definitions Aaron Lauterer
2024-11-11 18:23 ` [pve-devel] applied: " Thomas Lamprecht
2024-10-02 13:11 ` [pve-devel] [PATCH widget-toolkit v5 4/7] fix #3892: Network: add bridge vids field for bridge_vids Aaron Lauterer
2024-11-11 20:55 ` Thomas Lamprecht
2024-11-12 9:03 ` Aaron Lauterer
2024-11-12 9:55 ` Thomas Lamprecht
2024-11-12 10:29 ` Aaron Lauterer
2024-10-02 13:11 ` [pve-devel] [PATCH widget-toolkit v5 5/7] Network: add explanation for bridge vids field Aaron Lauterer
2024-11-11 20:49 ` Thomas Lamprecht
2024-10-02 13:11 ` [pve-devel] [PATCH manager v5 6/7] fix #3893: api: network: add bridge_vids parameter Aaron Lauterer
2024-10-02 13:11 ` [pve-devel] [PATCH manager v5 7/7] fix #3893: ui: network: enable bridge_vids field Aaron Lauterer
2024-11-12 9:47 ` [pve-devel] [PATCH common, widget-toolkit, manager v5 0/7] fix #3893: make bridge vids configurable Aaron Lauterer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=891a10ee-21f2-4c22-8313-0157289bd6a8@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=a.lauterer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox