Ken Fox wrote:
>
> my $f = (^x < ^max) ? ^x * ^scale : ^y * ^scale;
>
> has to be called
>
> &$f($x, $max, $scale, $y)
Hmm, perhaps we can use those named placeholders when calling the
function by a hash. And instead of generating a complete new code
reference, we can simply "build up" our function:
$f->(max=>$foo::maxval, scale=>$foo::rscale);
Leaving ^x and ^y unallocated, as per the original RFC23 (kinda). If the
placeholders are made flexible enough, we could have some fun:
$a = $f->@{x, y} = (40, 50); # set x and y by hash slice (syntax?)
$b = $f->(0, 100); # fill the remaining placeholders
$c = $f->(y=>-60, x=>-10); # the good ol' indeliable way
The question is, would all these different options work on coderefs? If
yes, that's one heck of an automagically generated subroutine
(especially for the hash slice example).
Also, how does the generated function ($f) know when to return it's
value or yet another coderef?
And can it be ab^H^Hused multiple times, as per the above, to generate
multiple values? (ala DBI::prepare once and sth->execute many)
Should we provide both methods of calling the function?
A) generating a new code ref by calling the original function in
scalar context (ie, $g = &$f('dog', 'cat')), and
B) "building up" a function by calling it in void context (ie,
$f->('dog'))
This smacks of closure and other anonymous-subroutine related issues.
Maybe I'm drifting off topic. Maybe I'm covering ground that's been trod
before. In any case, I'd like to hear what you guys think about this.
Especially Damian, because he's the poor sap writing the RFC. :-P
--
Mike Pastore
[EMAIL PROTECTED]
