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