Re: lvalue hash slice

* 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."