* Gaal Yahas <[EMAIL PROTECTED]> [2003-10-03 11:24]:
> Two points about this. First, the lvalue ?: is kinda, uh,
> Perlish to the extreme.
Yeah. It tends to be a powerful obfuscant too. I had to look
thrice at your code (then went "oh, duh!"). For more than two or
maybe three lvalues to switch between, I avoid it.
> And second, of course after I'd looked at it again it became
> clear it could be refactored to be even more succinct. If I'm
> willing to leave sortorder inside the frgrp structure[*], this
> can easily be remade:
>
> for (keys %$res) {
> $frgrp{$1}{$2} = $res->{$_}
> if /^frgrp_(\d+)_(name|public|sortorder)$/;
> $friend{$1}{$2} = $res->{$_}
> if /^friend_(\d+)_(user|name|groupmask|type)$/;
> }
Might be overkill in this case, but honouring "capture
similarities in code, differences in data", I might be inclined
to write this along the lines of
my %parse_type_for = (
frgrp => [ \%frgrp, 'name|public|sortorder' ],
friend => [ \%friend, 'user|name|groupmask|type' ],
);
for (keys %$res) {
my ($name) = /^([^_]+)/;
my ($type, $options) = @{$parse_type_for{$key}}
or next;
/^$name_(\d+)_($options)$/g
and $type->{$1}{$2} = $res->{$key};
}
I'm not happy with the name choice for ``$type'', but couldn't
think of a better term.
--
Regards,
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
