

RFC: Closures in PHP - mcxx
http://wiki.php.net/rfc/closures

======
henryw
i would like to see it done more like javascript with un-named function.
instead of:

    
    
         $replacement = function ($matches) {
           return str_replace ($matches[1], ' ', '&nbsp;').' ';
         };
    
         return preg_replace_callback ('/( +) /', $replacement, $text);
       
     
    

do:

    
    
         return preg_replace_callback ('/( +) /', function ($matches) {
           return str_replace ($matches[1], ' ', '&nbsp;').' ';
         }, $text);
    
    

and also make array_map more like Array.each(e) in js:

    
    
      $processed = array_map($array, function($e) {
    	return strtolower($e);
      });
    
    

and all the custom defined functions like usort:

    
    
      $processed = usort($array, function($a, $b) {
    	return $a > $b ? 1 : -1;
     });

~~~
thwarted
Those are great ideas, and with any kind of /decent/ parser and code generator
would be possible (because presumably the function expression returns a
function type, which can be stored in a variable or passed around). But this
is in PHP, were is_* functions ONLY work on "expressions" that look like
variables (not expressions that evaluate to values), and debug_backtrace,
while it returns an array, can not be indexed inline without assigning the
result of it to a variable first.

------
thwarted
Maybe they can finally remove the reference to "lambda" from the
create_function documentation, which is entirely false and blatantly
misleading.

------
rcoder
While I personally think that closures and lexical scoping are desirable
feature in any language, this seems a bit like putting lipstick on a pig to
me.

As a simple wrapper around various C libraries with automatic memory
management and higher-level syntax, PHP makes a certain kind of sense, warts
and all. As a general-purpose high-level language, I have to wonder exactly
what problem it solves that Perl, Ruby, and Python haven't already done
better.

What do you think the average newbie PHP developer is going to do the first
time they encounter a function which closes over a class instance as state,
and then returns a lambda?

The subtle interplay between reference vs. value calling conventions, PHP's
_weird_ scoping rules, and the new 'lexical' keyword seems like a sure source
of head-scratching for new developers, too.

~~~
nir
"I have to wonder exactly what problem it solves that Perl, Ruby, and Python
haven't already done better"

I don't know what, but evidence (Wikipedia, Facebook, Yahoo, Digg, Wordpress,
Drupal...) seem to say that there is _something_ PHP is doing significantly
better than all of these.

"What do you think the average newbie PHP developer is going to do the first
time they encounter a function which closes over a class instance as state,
and then returns a lambda?"

Perhaps they won't encounter this at all, but they might well be coding inside
a framework - whether light MVC or something like Drupal - that makes use of
this. For something to be useful it doesn't have to be useful for _everyone_
who use the language.

~~~
rcoder
> I don't know what, but evidence (Wikipedia, Facebook, Yahoo, Digg,
> Wordpress, Drupal...) seem to say that there is something PHP is doing
> significantly better than all of these.

I think that PHP is doing precisely what I said it was good at: wrapping high-
performance C libraries with a higher-level syntax for doing fast dynamic web
content generation.

It's not a good systems language, and features trying to make it more like one
always feel a bit "bolted-on."

> For something to be useful it doesn't have to be useful for everyone who use
> the language.

Actually, changes to core language syntax _aboslutely_ need to be considered
in light of their relevance to the entire user community, not just the most
experienced developers.

Most programmers spend far more time reading code than writing it. If you
increase the complexity of a language, (note: I mean _semantic_ complexity
here, not syntactic) you increase the difficulty involved in reading it.

In my not-so-humble opinion, PHP works when aimed at the lower end of the
semantic complexity scale. Trying to turn it into a general-purpose language
for "programming in the large" seems a rather unfortunate use of energy, given
(as you pointed out) its obvious success in its existing niche.

