-----Original Message-----
From: Lars Strojny [mailto:l...@strojny.net] 
> >I understand where this can be useful sometimes, but I disagree that this
> >should be added as a language feature. It is still possible to implement
> >this (parameter positioning in your curried function) using a function
> >that returns a closure similar to the curry_left example in the RFC. One
> >possible method (inspired by the C++ system for doing the same thing)
> >would be:
> >
> >$apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder
> >positioning object
> 
> Interesting idea to use placeholder argument as it is implementable in
> user space (or as a PECL extension or a bundled one) without touching the
> parser.  Maybe an arg()-Function which returns a placeholder object would
> be the way to go. Something like this maybe:
> 
> $apos = curry('strposŒ, arg(1), 'aŒ);

That would work too. The general idea for this type of implementation isn't 
mine. This is how C++ systems implement this, which is where the idea comes 
from. (See boost::bind)

I like your arg(n) syntax better, but worry about namespace collisions (but 
again, that's less of an issue when implemented in user code, rather than at 
the language level).

> >This isn't quite as nice as the proposed T_FILL, but on the other hand,
> >it is more powerful (parameters could change order) and isn't nearly as
> >confusing as the RFC syntax (which looks like perhaps strpos is being
> >called in some strange way).
> 
> Could you elaborate on how parameters could change order?

Yeah. Consider this:

$today_cookie = curry('setcookie', arg(1), arg(2), arg(4), 60*60*24, arg(3));

Originally, the order of parameters in setcookie is ($name, $value, $expire, 
$path, $domain, ...). this changes the order to ($name, $value, $domain, $path) 
(which is common for setcookie wrappers, because it is often a more useful 
order).

In any case, you can see how this type of implementation can be very flexible 
and tailored to specific application needs in a way that a language level 
implementation can't (for fear of bloat).

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to