On Aug 28, 2025, at 09:29, Daniel Gustafsson <daniel@yesql.se> wrote:
> A tiny nitpick is that all the other generator scripts (that I looked at) in
> the tree use GetOptions() with named parameter rather than dereference ARGV
> directly:
>
> +my $input_fname = $ARGV[0];
> +my $output_fname = $ARGV[1];
GetOptions() is overkill when there are no options. I’d opt for:
die "Usage: $0 INPUT_FILE OUTPUT_FILE\n" unless @ARGV == 2;
my ($input_fname, $output_fname) = @ARGV;
And since I griped about Perl style previously, I made a pass over modernizing it a bit. One might argue it’s less
clear,of course; there is less alignment of the printing than in the original. Otherwise, I’d note:
* Use the /r regex return sequence to simplify dquote() (requires Perl 5.14, IIRC)
* Iterate over the data types in a single line
* Pass lists of values to `print`
* Use {$fh} syntax to make file handle arguments clearer
But do with it what you will.
One other thing, as an aside, and probably not worth changing this patch: I’d prefer to see the use of explicit I/O
layers.IOW, rather than
open my $ofh, '>', $output_fname
Use the UTF-8 layer, which encodes strings as UTF-8 bytes:
open my $ofh, '>:utf8', $output_fname
Or perhaps use pure binary:
open my $ofh, '>:raw', $output_fname
Though then things like `ucfirst` won’t work properly for non-ASCII strings.
The default layer, when not specified, is Latin-1 (because 1994). It’s not a problem if we’re certain we’ll never use
anythingother than ASCII, but more explicit I/O layers would be clearer, IMO. I didn’t change it in the attached
becauseCatalog.pm doesn’t use an I/O layer, either, so it’s best if they’re consistent.
So, I guess, would there be interest in a patch to update I/O layer handling in the core Perl code?
Best,
David
