Re^2: Dynamic function chains?

The output I showed should have been for "power2" (or "exp2").. my mistake.

In your solution, you are not constructing a composite subroutine, but instead iterating over all of them in the loop: $val = $_->( $val ) for @ops;

Wouldn't a composite subroutine be more efficient?

There's a trivial mistake in your solution in that it performs the operations in the reverse order (which is fixed by using

reverse @ARGV

in the map statement).

I was aiming to keep the order, because then if you want:
f(g(h(x)))
you can say:
funcs.pl -f -g -h

Comment on Re^2: Dynamic function chains? Download Code

Replies are listed 'Best First'.
Re^3: Dynamic function chains? by BrowserUk (Patriarch) on Sep 15, 2004 at 15:26 UTC
Wouldn't a composite subroutine be more efficient? Generally, evaling at runtime is quite expensive. You'd have to benchmark to say for sure. I guess it depends upon how many time your going to call the composite sub. If your processing large datasets, the cost of eval may become insignificant. I usally avoid evaling stuff input from the command line, though ]broquaint]'s use of package->can() seems to avoid most of the risks that usually entails. I liked his solution a lot. Yes, I screwed up the order. reverse is the easiest solution. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply]

Replies are listed 'Best First'.

Re^3: Dynamic function chains?
by BrowserUk (Patriarch) on Sep 15, 2004 at 15:26 UTC

Wouldn't a composite subroutine be more efficient?

Generally, evaling at runtime is quite expensive. You'd have to benchmark to say for sure. I guess it depends upon how many time your going to call the composite sub. If your processing large datasets, the cost of eval may become insignificant.

I usally avoid evaling stuff input from the command line, though ]broquaint]'s use of package->can() seems to avoid most of the risks that usually entails. I liked his solution a lot.

Yes, I screwed up the order. reverse is the easiest solution.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

[reply]