Chris Nandor wrote:

The full example would be long, so I won't include it here, but I will describe an issue I ran across. I had to learn some code written by an old Lisp fan. He had to deal with a table of data, each column of which needed its own formatting and validation rules. So he had a hash of information about each column, one field of which had a key called "format" which was the anonymous subroutine to format that field correctly. So you had a construct that looked like this:

print join ",", map { &{$field_info{$_}{format}}($deal) } @fields;

It took me some time to figure out what that construct meant and where the actual formatting information was. His argument was that this was a perfectly fine thing to do. He did it all of the time, and it allowed you to separate presentation from content. He admitted that the first time you saw it, it looked a bit strange, but if you knew what it did...

That turned out to be a good lesson for me. This construct really was integral to his style, and once I got past the shock of that line it really was maintainable. You had a very well defined section of the code that was straight configuration information, and a different well-defined section of the code that was logic, and then the magic bit that combined them was very short, and almost never was what you had to change.

But I still believe that the above construct is either something you do consistently or something you should never try at all. Either declare it part of the learning curve or else avoid it. But do not randomly subject people to it...

Cheers, Ben

PS I later rewrote this to a faster and simpler form:

my @field_subs = map {$field_info{$_}{format}} @fields; # time passes print join ",", map {&$_($deal)} @field_subs;