Re^7: How A Technique Becomes Over-rated

[Ctrl-z]

I don't think that's a fair characterization

You are right (though it might be the point), I had changed it while you were responding. Regarding your analogy, you might be annoyed that I leave with your plate and fork and carry it wherever I go, even after you move out - and noone believes you as the plate and fork are now invisible to everyone ;-)

I appreciate what you are saying, and to quote from HOP

...I think the functional style leads to a lighter-weight solution...that keeps the parameter functions close to the places they are used instead of stuck off in a class file. But the important point is that although the styles are different, the decomposition of the original function into useful components has exactly the same structure.

The point about closesness is a good one. Its not possible in OO Perl and only kind of possible in Java, as I tried to show in an earlier post. But, by limiting your customization technique to callbacks, all shared state must be stored in the lexical scope of the caller. By limiting your object to a coderef, theres only one thing you can do with it - call it. Thats fine for simpler stuff - number generators, map, grep etc - and I like those kind of ideas. But its definitely not the tool I know for building relatively complicated software.

[Anonymous Monk]

But, by limiting your customization technique to callbacks, all shared state must be stored in the lexical scope of the caller.

($foo, $bar)  = incrementByOneAndTwo(42);
($baz, $quux) = incrementByOneAndTwo(0);

$\="\n";
print $foo->();
print $bar->();
print $quux->();
print $foo->();
print $baz->();
print $bar->();
print $quux->();

sub incrementByOneAndTwo
{
    my $shared_state = shift;

    return (sub{$shared_state+=1}, sub{$shared_state+=2});
}