On Thu, Oct 02, 2003 at 09:39:53PM -0000, [EMAIL PROTECTED] wrote: > > Has this always worked? I coulda sworn I tried it in the past > > with no luck... > > It has always worked since I started Perl (sometime around 5.4). > > I'd make an educated guess that it has been available at least as > long as C<(LIST)[EMAIL PROTECTED]> has. That would mean at least ever > since Perl5; likely as early as Perl4.
Oh well. I think I started around when 5.003 was all new, but so was I; I guess my attempts were just ungrammatical then and ever since I had assumend this just doesn't work. > > Okay, score down for solution, score up for obfuscation...! :p > > Why obfuscation? Hash slice as lvalue is extremly elegant and > *very* readable in my opinion. It requires very little verbiage > and communicates the intent clearly. Oh, I didn't mean that lvalue hash slices are an obfuscation. Just that my unneccessary workaround for their alleged lack of existence was. I agree they are a very elegant concept: that's why I was looking for a workaround in the first place. > For me, Perl's extremly expressive data structure access syntax > and its ability to operate on lists without the programmer having > to explicitly iterate is pretty much the main selling point of > the language. I *very* much miss it when I try to work with > machine oriented languages. > > If I had a nickel for every time I've written > "for (i = 0; i < N; i++)" in C I'd be a millionaire. > -- Michael Vanier Yeah. To cheer myself up from the embarassment of the original post, I dug up some old code of mine. For context, it takes a LiveJournal protocol response, which is basically a flattened data structure, and rearranges it into a clearer and probably more useful deep structure: (The number is an id to which this item refers. On the wire, results travel as key\nvalue; that is trivially converted to a hash.) foreach (keys %$res) { /frgrp_(\d+)_name/ ? $frgrp{$1}{name} : /frgrp_(\d+)_public/ ? $frgrp{$1}{public} : /frgrp_(\d+)_sortorder/ ? $grpord{$1} : /frgrp_maxnum/ ? $maxnum : /friend_(\d+)_user/ ? $friend{$1}{user} : /friend_(\d+)_name/ ? $friend{$1}{name} : /friend_(\d+)_groupmask/ ? $friend{$1}{groupmask} : /friend_(\d+)_type/ ? $friend{$1}{type} : undef = $res->{$_} : } Two points about this. First, the lvalue ?: is kinda, uh, Perlish to the extreme. 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)$/; } And one line shorter if I'm willing to unstrict for a while or if I can live with a deeper structure. [*] As for sorting frgrps, that would then of course be made @sorted_ids = sort { $frgrp{$a}{sortorder} <=> $frgrp{$b}{sortorder} } keys %frgrp; ...or @sorted_frgrps = map { $frgrp->{$_} } sort ... Oh, and maxnum can actually be ignored in all this. It's mostly there for c implementations anyway, that want to know how much memory to allocate in advance. -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/