(Sorry if you get this twice, Antony. I didn't hit 'Reply to all' the
first time)

On Dec 20, 2007 10:19 AM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 20.12.2007 11:18, Alexey Zakhlestin wrote:
> > On 12/20/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> >> On 20.12.2007 09:57, Alexey Zakhlestin wrote:
> >> > being able to do the following (and not to worry about runtime
> >> > compilation) is a good reason on it's own:
> >> >
> >> > array_filter($my_data, function($test){ return 3 === ($test % 4) });
> >>
> >> Oh, my..
> >> This code clearly demonstrates why a syntax like this should not be 
> >> allowed. Ever.
> >
> > you prefer cluttering namespace with a lot of oneliners?
>
> Oh, come on.. Since when do we call it "cluttering"?
> Is there some kind of limit on number of functions in a namespace?

Yes there is. Or more precise, there is a limited to the number of
sanely named functions.

> Why limit yourself and "inline" the function instead of putting it
> into a nice library of utility functions?
>
> > currently, people prefer to use explicit cycles instead of
> > array_map/array_filter and that looks ugly (hides actual logic behind
> > syntax), but at least it is not as slow as create_function.
>
> Whatever people currently use - it's their choice.
> If you think that people would magically switch to the new syntax (if we 
> decide to
> add it after all) in a moment, I'm afraid I have to upset you - this will not 
> happen
> in the next 10 years because of many reasons, so people would still use the 
> good
> old syntax they're used to.

I don't care what other people do with their code base. I don't want
to impose anything on them. I just want to not get a headache, when
reading my own.

> So here is what we _actually_ get with this anonymous function syntax:
> 1) Yet another way to make the code unreadable and overcomplicated.
> 2) Yet another incompatible syntax you cannot use if you need to support 
> older PHP versions
> (and you can't check for it in runtime, since this is a compile time thingie).

By that standard, we should never change anything in PHP. Ever.

I'm not proposing to roll this out with the next minor release. PHP6
is happening soon; It could include this patch. Of course, if we
postprone it long enough, we will have to wait for PHP7.

> 3) 10 people happy because they got a new toy.

I don't know how to respond to that, without being rude, so I won't.


-- 
troels

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

Reply via email to