-----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