Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Right, PHP is not Javascript. But, PHP has been used alongside Javascript more and more lately (consider AJAX and all that good stuff), so folks who program in both would be helped by having a construct that is both clean, readable, and similar between languages. -Andrei Stanislav Malyshev wrote: That makes perfect sense to me as I see/use this sort of code in JavaScript. Well, PHP is not Javascript - and BTW Javascript is a complex language and I don't think we should import that complexity into PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Anthony,
It may be disagreeable from your perspective, but I (and many others)
find this to be a very useful construct. And I hate to invoke "other
languages" argument, but there is a reason that something like this is
available in many modern languages - it is useful.
-Andrei
Antony Dovgal 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 20, 2007 7:02 PM, Sean Coates <[EMAIL PROTECTED]> wrote:
> Apart from saving a few keystrokes, the above could easily be changed
> to the following, which is much more clear, DOES compile at compile-
> time, and works without adding a new construct that looks like a
> closure, but is not indeed one:
>
> function aiusdyasdjkhasdIMASHEDTHEKEYBOARD($test){ return 3 === ($test
> % 4) }
> array_filter($my_data, 'aiusdyasdjkhasdIMASHEDTHEKEYBOARD');
>
I'm not sure. Are you using this as an argument _for_ or _against_?
Because to me, that looks ridiculous.
It won't work either. You have to add guards, to prevent a fatal
error, if you include the file twice. So the entire "solution" would
be:
if (!function_exists('aiusdyasdjkhasdIMASHEDTHEKEYBOARD')) {
function aiusdyasdjkhasdIMASHEDTHEKEYBOARD($test){ return 3 === ($test % 4); }
}
array_filter($my_data, 'aiusdyasdjkhasdIMASHEDTHEKEYBOARD');
> At risk of wading into yet circular another discussion on internals@,
> I was part of the original thread on this subject, and I agree with
> Stas here: unless they're real closure, they're pretty useless.
I don't believe that has been Stanislavs point so far. As I understand
it, he says that adding the syntax, without adding closures, may
confuse people, who then will intuitively expect closures. That is not
the same as saying, it is useless.
On the point of uselessness, I have already explained how it would be
a useful construct.
On Dec 20, 2007 7:09 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > and you did it again :-) Not working? What the hell are you talking of?
> > We can easily make it working with whatever feature set we want. We do not
>
> We meaning who? I can't "easily" make closures working in PHP. And even
> if I could, I'm not sure I want to.
I agree fully. Static scope should not be implemented in PHP. Could we
discus the patch, rather than something, which is purely theoretical
and only marginally related?
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
1) you need to declare them somewhere, which doesn't make much sense if these functions are meant to be used only in such context. If you need them in context, you can declare them in context. Sometimes there are even problem to give meaningful names to such functions Just describe what it does. If it is not unique, then the function is not unique. 2) inline-function is a good candidate for automatic optimization (in case of array_filter, array_map and similiar the construction can be converted to the loop) We have neither such optimizations nor any plans to make those, AFAIK. 3) as the result of (1) and (2) it can be used for fast "currying" of other functions And why we need fast currying of other functions? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
and you did it again :-) Not working? What the hell are you talking of? We can easily make it working with whatever feature set we want. We do not We meaning who? I can't "easily" make closures working in PHP. And even if I could, I'm not sure I want to. support any feature ever thought of for everything in PHP. For instance our object model has no abstract with default body, no MI, no delegates, no overloading Your point being? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
That makes perfect sense to me as I see/use this sort of code in JavaScript.
Well, PHP is not Javascript - and BTW Javascript is a complex language
and I don't think we should import that complexity into PHP.
The argument about making the filter a global function is not sensible
to apply in all circumstances. In many cases the filter is only going
to be of use in an array_filter() call, so now we would have 2
functions to do the work of 1.
No, we won't - both cases have only one function, if you don't count
array_filter(), and two, if you do.
Maybe a syntax like this would be more appealing ...
array_filter($my_data as $test) {
return 4 === ($test % 4);
}
No, it won't be. If you are looking for Scheme or Ruby, you know where
to find it :)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
array_filter($my_data, function($test){ return 3 === ($test % 4) });
What's wrong with regular functions?
At risk of wading into yet circular another discussion on internals@,
I was part of the original thread on this subject, and I agree with
Stas here: unless they're real closure, they're pretty useless.
Apart from saving a few keystrokes, the above could easily be changed
to the following, which is much more clear, DOES compile at compile-
time, and works without adding a new construct that looks like a
closure, but is not indeed one:
function aiusdyasdjkhasdIMASHEDTHEKEYBOARD($test){ return 3 === ($test
% 4) }
array_filter($my_data, 'aiusdyasdjkhasdIMASHEDTHEKEYBOARD');
// I copy & pasted the callback name; aren't modern computers
fascinating?! (-:
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/20/07, Stanislav Malyshev <[EMAIL PROTECTED]> 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) });
>
> What's wrong with regular functions?
I wrote in in thread, already, but here is the summary:
1) you need to declare them somewhere, which doesn't make much sense
if these functions are meant to be used only in such context.
Sometimes there are even problem to give meaningful names to such
functions
2) inline-function is a good candidate for automatic optimization (in
case of array_filter, array_map and similiar the construction can be
converted to the loop)
3) as the result of (1) and (2) it can be used for fast "currying" of
other functions
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
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) });
What's wrong with regular functions?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Am 20.12.2007 um 10:19 schrieb Antony Dovgal:
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?
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 think you're wrong. There are, especially recently, many examples of
libraries, frameworks and products that require a very recent version
of PHP. Not to mention "internal" projects, hosted services etc etc
etc where supporting legacy versions does not matter.
array_map($array, function($item) { return $item['foo'] == 'bar'; });
etc would be a brilliant way of making code more maintainable and
readable. most people don't create a special function for this, and
also don't use create_function, but instead write difficult to
understand loops or other constructs to process the data.
The point is that creating a function or method just for one array_map
call indeed _does_ clutter the namespace with unnecessary stuff.
Inline functions are elegant and make code more readable and
maintanable, and that should be reason enough to have them.
Best regards,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/20/07, Antony Dovgal <[EMAIL PROTECTED]> wrote: > No problem, one email more, one email less.. =) > > I don't know what else I can add, so I can only repeat myself: > http://daylessday.org/archives/12-Lets-add-this,-lets-add-that.html a major difference: this time there is a patch -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 20.12.2007 12:46, troels knak-nielsen wrote: > (Sorry if you get this twice, Antony. I didn't hit 'Reply to all' the > first time) No problem, one email more, one email less.. =) I don't know what else I can add, so I can only repeat myself: http://daylessday.org/archives/12-Lets-add-this,-lets-add-that.html -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 20.12.2007 12:41, Alexey Zakhlestin wrote: > it doesn't make sense to put some of these functions in libraries, > because they are really once-used. It makes perfect sense to keep all your functions in one place instead of spreading them all over the code. And no, this kind of "optimization" doesn't make your code run any faster. >> So here is what we _actually_ get with this anonymous function syntax: >> 1) Yet another way to make the code unreadable and overcomplicated. > it is not unreadable. it is perfectly readable for people with > modern-languages background (and I don't mean 1 or 2 languages, I mean > majority) A new syntax that conflicts with currently existing one (or looks very similar to) doesn't make code more readable, it adds more confusion instead. >> 3) 10 people happy because they got a new toy. > "thousands" is a closer number Does this mean you do admit that this is just a new toy? (pretty useless, but funny) =) -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello Stanislav, and you did it again :-) Not working? What the hell are you talking of? We can easily make it working with whatever feature set we want. We do not support any feature ever thought of for everything in PHP. For instance our object model has no abstract with default body, no MI, no delegates, no overloading Back to functions. Given the long discussion about handling the non easy stuff I think we should go with the usual PHP approach here, "Keep It Simple Safe". As in keep everything that has to be discussed to death out. Why? Because it allows nice stuff and has often be requested. marcus Wednesday, December 19, 2007, 11:21:20 PM, you wrote: >> So how big a part of PHP's userbase is that? I'm guessing, it's small. > If it's small, we don't need it in the language anyway. >> True, but the people who will anguish over lack of closures, are >> already tearing their hair out over create_function(). > Having no function and knowing it is better than having something that > looks like it but doesn't work. Saves time that would be spent > unsuccessfully trying to make it work. > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/20/07, Antony Dovgal <[EMAIL PROTECTED]> wrote: > On 20.12.2007 12:41, Alexey Zakhlestin wrote: > > it doesn't make sense to put some of these functions in libraries, > > because they are really once-used. > > It makes perfect sense to keep all your functions in one place instead of > spreading them all over the code. > And no, this kind of "optimization" doesn't make your code run any faster. if this was a comment to inline-optimization I mentioned, then it actually would make my code run faster (I use PHP for quite unusual tasks) > >> So here is what we _actually_ get with this anonymous function syntax: > >> 1) Yet another way to make the code unreadable and overcomplicated. > > it is not unreadable. it is perfectly readable for people with > > modern-languages background (and I don't mean 1 or 2 languages, I mean > > majority) > > A new syntax that conflicts with currently existing one (or looks very > similar to) > doesn't make code more readable, it adds more confusion instead. should we change "function" word on "lambda" word there to make confusion smaller? > >> 3) 10 people happy because they got a new toy. > > "thousands" is a closer number > > Does this mean you do admit that this is just a new toy? (pretty useless, but > funny) =) I admit, that I do programming, because it is fun If it is not fun, I get bored and switch to other task this functionality would make programming of some tasks more fun and, as result, will lead to greater productivity -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
(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
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 20/12/2007, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote:
> On 12/20/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > > I think we need it. In the current incarnation, anonymous functions
> > > are so impractical to use, that it's a barrier. I think that is
> > > unfortunate, because it could be an interesting and useful direction
> > > to take for PHP. The users, who don't know what a closure is, could
> >
> > Direction like what?
>
> 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) });
That makes perfect sense to me as I see/use this sort of code in JavaScript.
The argument about making the filter a global function is not sensible
to apply in all circumstances. In many cases the filter is only going
to be of use in an array_filter() call, so now we would have 2
functions to do the work of 1.
If you think about for() and foreach(), these are functional-ish
ideas. Iterators in general should quite happily support this idea.
Maybe a syntax like this would be more appealing ...
array_filter($my_data as $test) {
return 4 === ($test % 4);
}
This sort of looks like a foreach, which is extremely readable.
Richard.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/20/07, Antony Dovgal <[EMAIL PROTECTED]> wrote: > > 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? > > Why limit yourself and "inline" the function instead of putting it > into a nice library of utility functions? it doesn't make sense to put some of these functions in libraries, because they are really once-used. another good reason is, that optimizer can safely inline this function by eliminating function call at all (using cycle as an internal representation, while letting keep short one in source) > > 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. > > So here is what we _actually_ get with this anonymous function syntax: > 1) Yet another way to make the code unreadable and overcomplicated. it is not unreadable. it is perfectly readable for people with modern-languages background (and I don't mean 1 or 2 languages, I mean majority) > 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). yes > 3) 10 people happy because they got a new toy. "thousands" is a closer number -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
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?
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.
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).
3) 10 people happy because they got a new toy.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
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?
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.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PATCH: anonymous functions in PHP
>Oh, my.. >This code clearly demonstrates why a syntax like this should not be >allowed. Ever. This code is exactly what I wrote, personally, when I wanted to use anonymous functions for the first time in PHP. And I guess I have not been the only one. Could you explain in what way it "clearly demonstrates" ?? Baptiste Autin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
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.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/20/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > I think we need it. In the current incarnation, anonymous functions
> > are so impractical to use, that it's a barrier. I think that is
> > unfortunate, because it could be an interesting and useful direction
> > to take for PHP. The users, who don't know what a closure is, could
>
> Direction like what?
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) });
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 20, 2007 1:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > > Well, the whole functional programming thing. > > But PHP is not an FP language and wasn't built to be one. If one needs > an FP language, why not look into languages built with that purpose? We can change it then. PHP wasn't built to be object oriented either. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Well, the whole functional programming thing. But PHP is not an FP language and wasn't built to be one. If one needs an FP language, why not look into languages built with that purpose? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 20, 2007 12:44 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > > I think we need it. In the current incarnation, anonymous functions > > are so impractical to use, that it's a barrier. I think that is > > unfortunate, because it could be an interesting and useful direction > > to take for PHP. The users, who don't know what a closure is, could > > Direction like what? Well, the whole functional programming thing. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
I think we need it. In the current incarnation, anonymous functions are so impractical to use, that it's a barrier. I think that is unfortunate, because it could be an interesting and useful direction to take for PHP. The users, who don't know what a closure is, could Direction like what? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 19, 2007 11:21 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > > So how big a part of PHP's userbase is that? I'm guessing, it's small. > > If it's small, we don't need it in the language anyway. I think we need it. In the current incarnation, anonymous functions are so impractical to use, that it's a barrier. I think that is unfortunate, because it could be an interesting and useful direction to take for PHP. The users, who don't know what a closure is, could still learn to use anonymous functions and they would then not assume closures. So even if the user base is small initially (naturally, since the feature doesn't exist), it could grow. And for the rest of us, it's at least better than create_function(). > Having no [closure] and knowing it is better than having something that > looks like it but doesn't work. Saves time that would be spent > unsuccessfully trying to make it work. (I assume you meant closure?) It can still work, without closures. Not all anonymous functions need variable input and if they do, you can use currying. Admittedly, currying has its own practical issues in PHP, but that's a separate discussion. (And one, I'd like to take at a later time for that matter) The point is, that static lambda still has something to offer, even if it doesn't allow closures. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
So how big a part of PHP's userbase is that? I'm guessing, it's small. If it's small, we don't need it in the language anyway. True, but the people who will anguish over lack of closures, are already tearing their hair out over create_function(). Having no function and knowing it is better than having something that looks like it but doesn't work. Saves time that would be spent unsuccessfully trying to make it work. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 18, 2007 12:41 AM, Jeff Moore <[EMAIL PROTECTED]> wrote: > Reading the prior discussion, I think either $_SCOPE['x'] or the > lexical $x syntax is fine for accessing local variables in the > enclosing scope. But closures also should also support $this and > static:: when the closure is defined in a method. While I realise that the possibilities of static scope in PHP, are intriguing, I really think it's a whole different discussion. Related, yes. Interesting, yes. But let's keep it separate, to avoid derailing the whole discussion. On Dec 17, 2007 8:46 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > While we are at it, what's wrong with knowing the name? I can see why > closure can be fun when you can dynamically use outer-scope variables. > But when you can't, what exactly prevents one from just doing the function? If the code block, which needs to create the function, could be run more than once, it would try to define the function twice, leading to a fatal error. Yes, I could guard it with is_function_defined(), but that wouldn't be pretty. Technically speaking, you're right, but I think aesthetics does have some weight. Or should. It's also my main gripe against create_function() in the first place. On Dec 17, 2007 8:46 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > First, about 100% on the first encounter for any user ever seeing > closures in any other language. Second, all the confusion possible, like So how big a part of PHP's userbase is that? I'm guessing, it's small. On Dec 17, 2007 8:46 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > closures in any other language. Second, all the confusion possible, like > "oh, closures! cool! let me do this and that! what, I can't use > variables?! Are you kidding me?! WTF is it useful for?!" True, but the people who will anguish over lack of closures, are already tearing their hair out over create_function(). On Dec 17, 2007 8:46 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > I'm not sure I understand what you mean by "static scope" and "dynamic > scope", ... Static scope is a synonym for lexical scope. On Dec 17, 2007 8:46 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > scope", but anyway thing that looks like closure but works like regular > function definition that isn't - is not a very good idea, IMO. Yes, that's the primary problem with the patch. I don't think it's as big an issue, as you do and given the alternatives, I'm willing to make that sacrifice. How's other peoples take on this point? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Monday 17 December 2007, Jeff Moore wrote:
> On Dec 17, 2007, at 10:30 PM, Larry Garfield wrote:
> > I'm assuming that making the function above GC-able would be a
> > herculean task
> > at this point, based on previous comments, but I do not actually
> > know myself.
>
> Hi Larry,
>
> Let me use a different example than yours.
>
> function getAdder($x) {
>return function ($y) {
> lexical $x;
> return $x + $y;
>}
> }
>
> $plusFive = getAdder(5);
> $plusTen = getAdder(10);
>
> echo $plusFive(4); // 9
> echo $plusTen(7); // 17
>
> If the closure definition (and thus getAddr) returns a string
> representing an anonymous function name, then there is no where to
> hold the enclosing variable $x and no way to know when to free it.
> Notice that in this example, we have two different enclosing contexts,
> one where $x is 5 and one where $x is 10.
>
> If we introduce a new variable type, a new kind of zval, then
> internally, that variable can hold:
> 1) A reference to the local variables of getAddr. (here $x)
> 2) A reference to $this if the closure is declared in a method
> 3) A reference to the opcodes of the compiled anonymous function.
>
> The opcodes for the closure would be compiled and squirreled away when
> the script is compiled.
>
> When getAddr is executed, a zval would be created that holds the
> reference to the enclosing locals and a reference to the proper
> opcodes. Note that $plusFive and $plusTen would hold two different
> zvals, one for each invocation of getAddr, but that both would refer
> to the same opcodes structure.
So the compiled code is then single-sourced, much the same way that a class is
single sourced and objects simply contain references to it. The Objects can
be GCed whenever, but the class opcodes remain for the life of the script.
> When a codeblock zval is executed, such as at $plusFive(4), the
> enclosing context can be passed to the anonymous function function to
> make the lexical $x statement bind to the proper variable.
>
> When the zval in $plusFive reaches zero references, it can
> subsequently free its references to the local variables of getAddr.
>
> As far as I can see, no herculean garbage collection or reference
> counting is required.
By separating the opcodes from the zval, you've side-stepped the need to do
so. That means declaring a dynamic function (or lambda, or whatever we end
up calling this thing) inside a loop is no more expensive than instantiating
a class inside of a loop. I'm glad you know more about engine internals than
I do. :-)
> Adding a new kind of zval? Perhaps that's Herculean. I don't know.
It sounds (to the layman) like it could/should be modeled on the way
objects/classes are implemented in PHP 5, as "fancy references". (I believe
Sara Golemon had an article a while back that explained them that way. Sara,
my apologies if I am misquoting you.) Whether that's a "new type of zval" or
not I do not know.
> I hope I've gotten my zval terminology right.
Better than mine would be. :-) And it seems to solve most of the
implementation concerns that were raised earlier, at least at an abstract
level. The catch would be that I don't know the performance impact of making
the compiler find and define these sorts of functions. Can someone with more
engine experience weigh in if the above is workable?
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 17, 2007, at 10:30 PM, Larry Garfield wrote:
I'm assuming that making the function above GC-able would be a
herculean task
at this point, based on previous comments, but I do not actually
know myself.
Hi Larry,
Let me use a different example than yours.
function getAdder($x) {
return function ($y) {
lexical $x;
return $x + $y;
}
}
$plusFive = getAdder(5);
$plusTen = getAdder(10);
echo $plusFive(4); // 9
echo $plusTen(7); // 17
If the closure definition (and thus getAddr) returns a string
representing an anonymous function name, then there is no where to
hold the enclosing variable $x and no way to know when to free it.
Notice that in this example, we have two different enclosing contexts,
one where $x is 5 and one where $x is 10.
If we introduce a new variable type, a new kind of zval, then
internally, that variable can hold:
1) A reference to the local variables of getAddr. (here $x)
2) A reference to $this if the closure is declared in a method
3) A reference to the opcodes of the compiled anonymous function.
The opcodes for the closure would be compiled and squirreled away when
the script is compiled.
When getAddr is executed, a zval would be created that holds the
reference to the enclosing locals and a reference to the proper
opcodes. Note that $plusFive and $plusTen would hold two different
zvals, one for each invocation of getAddr, but that both would refer
to the same opcodes structure.
When a codeblock zval is executed, such as at $plusFive(4), the
enclosing context can be passed to the anonymous function function to
make the lexical $x statement bind to the proper variable.
When the zval in $plusFive reaches zero references, it can
subsequently free its references to the local variables of getAddr.
As far as I can see, no herculean garbage collection or reference
counting is required.
Adding a new kind of zval? Perhaps that's Herculean. I don't know.
I hope I've gotten my zval terminology right.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Let me see if I'm understanding you correctly, because that sounds like the
line I'd been thinking along.
--
function baz() {
$var = 5;
$foo = function($a, $b) {
lexical $var;
return $a + $b + $var;
}
return $foo;
}
$func = baz();
function bar($func) {
return $func(2, 3);
}
echo bar($foo); // prints 10
--
Right? Would it be possible to push the heavy lifting onto the compiler
rather than runtime in the above case?
I'm assuming that making the function above GC-able would be a herculean task
at this point, based on previous comments, but I do not actually know myself.
On Monday 17 December 2007, Jeff Moore wrote:
> Hello,
>
> Reading the prior discussion, I think either $_SCOPE['x'] or the
> lexical $x syntax is fine for accessing local variables in the
> enclosing scope. But closures also should also support $this and
> static:: when the closure is defined in a method.
>
> I think a solution for closures should add a new variable type. That
> way, the code can compiled at compile time, while the enclosing
> context (local variables plus $this for methods) can be captured at
> run time in the new variable type. Also, when the closure value is
> garbage collected, the references to the enclosing scope and object
> instance can also be freed.
>
> Additionally, the callback psuedo-type could be promoted to the new
> type, with the string or array representation converted when
> required. It wouldn't be necessary, but a callback literal along the
> lines of Array() could also be added to make the conversion
> unnecessary. I find the following to be easier to understand:
>
> set_error_handler(Callback("foo"));
>
> Than
>
> set_error_handler("foo");
>
> The current syntax would still work because of automatic type
> conversion.
>
> Best Regards,
>
> Jeff
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello,
Reading the prior discussion, I think either $_SCOPE['x'] or the
lexical $x syntax is fine for accessing local variables in the
enclosing scope. But closures also should also support $this and
static:: when the closure is defined in a method.
I think a solution for closures should add a new variable type. That
way, the code can compiled at compile time, while the enclosing
context (local variables plus $this for methods) can be captured at
run time in the new variable type. Also, when the closure value is
garbage collected, the references to the enclosing scope and object
instance can also be freed.
Additionally, the callback psuedo-type could be promoted to the new
type, with the string or array representation converted when
required. It wouldn't be necessary, but a callback literal along the
lines of Array() could also be added to make the conversion
unnecessary. I find the following to be easier to understand:
set_error_handler(Callback("foo"));
Than
set_error_handler("foo");
The current syntax would still work because of automatic type
conversion.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Functionally, create_function() is a variation of eval, which allows you to create new code at runtime. Static lambda is syntactic sugar for creating a function in the global scope, without knowing its name at compile time. Static lambda is more restrictive than While we are at it, what's wrong with knowing the name? I can see why closure can be fun when you can dynamically use outer-scope variables. But when you can't, what exactly prevents one from just doing the function? two considerations to take here; First, how probable is it, that users will make this assumption? And second, how much confusion will it cause to those, which it affects? First, about 100% on the first encounter for any user ever seeing closures in any other language. Second, all the confusion possible, like "oh, closures! cool! let me do this and that! what, I can't use variables?! Are you kidding me?! WTF is it useful for?!" place. The simple rule, that PHP has dynamic scope, should be simple to understand for anyone who actually knows the difference. I'm not sure I understand what you mean by "static scope" and "dynamic scope", but anyway thing that looks like closure but works like regular function definition that isn't - is not a very good idea, IMO. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello Stanislav, I do not see anything broken here. All I see is discussing a patch to death just because it doesn't do what everybody wants. marcus Monday, December 17, 2007, 6:14:22 PM, you wrote: >> and for that reason we should do it! Can't Wez simply apply this? > I think we saw numerous examples that "commit first, think later" > approach is not the best one... > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 17, 2007 6:09 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote: > Don't have time right now but we should go back and re-read those > discussions before opening a new one. I can probably do it over the next > couple of days. I am not necessary against supporting such a solution > but we need to make sure it's fully baked and that we clear know and > agree on what is and what isn't supported (and that should be documented > and not revisited every time someone comes and complains). Variable > binding is one thing which would likely not make it into such an > implementation unless there's a big shift in the intent of the patch. Allow me to recap then. Static lambdas (in lack of a better name) and create_function() differ from each other in that the former happens at compile time, while the latter happens at run time. The consequence of this is, that you can bind (primitive) variables to the created function, with create_function(), but not with static lambdas. Functionally, create_function() is a variation of eval, which allows you to create new code at runtime. Static lambda is syntactic sugar for creating a function in the global scope, without knowing its name at compile time. Static lambda is more restrictive than create_function(), because there is no way to share scope between the inner and the bounding function. This is specific for PHP, because the language doesn't have static scope. Without going much into details, I think it's pretty safe to say, that introducing static scope into PHP is not only undesireable, but also technically impossible. So let's not spend any time discussing that. In brief, there are the following benefits of introducing static lambdas: A1 Better readability. A2 Syntactic errors happen at compile time, rather than run time. A3 Better support for debugging/introspection. A4 Optimisations are possible. And the following problems: B1 Users might assume, that lambdas have static scope. B2 There is some overlap between the application of create_function() and static lambdas, meaning some level of redundancy. B3 Static lambdas are less powerful, since there is no way to bind variables. If I missed any points, please bring them up. Otherwise, this is what a decision should be based on. (And sorry for pointing out the obvious, but _not_ making a decision, is a decision too) Of the cons, B1 is probably the biggest issue. There are (at least) two considerations to take here; First, how probable is it, that users will make this assumption? And second, how much confusion will it cause to those, which it affects? The first question could perhaps be answered by a survey (Or less scientifically, by random consensus), but the latter is rather subjective. I'd like to make the argument, that those who will tend to suffer most from peculiarities of scoping rules, are the same people, who are less likely to have encountered static scope in the first place. The simple rule, that PHP has dynamic scope, should be simple to understand for anyone who actually knows the difference. Did I miss anything? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Well, documentation can include the following written using large font: Warning: This is not a closure. PHP doesn't have native means for nested contexts. This construct is just another way of creating usual function during compile-time. (for creating functions in run-time see create_function) It doesn't help. Nobody reads the docs if he thinks he understands how it should work anyway. Having disclaimer in the manual doesn't do much - we are not worried about being sued, we are worried about feature looking one way and actually working other way. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Andi Gutmans wrote: > We really need to get away from this "let's just commit it" mode on this > list. As you saw with garbage collection, namespaces and other recent > topics a lot of these topics need significantly more work before they > are full baked and ready to actually make it into the code base. The > ad-hoc way of committing new features just doesn't work. Amen to that. A long time ago we wanted to use text files in an RFC directory in CVS to discuss new language features. Maybe we should resurrect this idea? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
and for that reason we should do it! Can't Wez simply apply this? I think we saw numerous examples that "commit first, think later" approach is not the best one... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PATCH: anonymous functions in PHP
I actually remember there was some good discussion on this and there were pretty decent reasons for why this patch was not a full solution and only syntactic sugar, i.e. it didn't do what many expected except for making the syntax nicer. Don't have time right now but we should go back and re-read those discussions before opening a new one. I can probably do it over the next couple of days. I am not necessary against supporting such a solution but we need to make sure it's fully baked and that we clear know and agree on what is and what isn't supported (and that should be documented and not revisited every time someone comes and complains). Variable binding is one thing which would likely not make it into such an implementation unless there's a big shift in the intent of the patch. We really need to get away from this "let's just commit it" mode on this list. As you saw with garbage collection, namespaces and other recent topics a lot of these topics need significantly more work before they are full baked and ready to actually make it into the code base. The ad-hoc way of committing new features just doesn't work. Andi > -Original Message- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Monday, December 17, 2007 5:10 AM > To: Alexey Zakhlestin; Wez Furlong > Cc: Stas Malyshev; troels knak-nielsen; internals@lists.php.net > Subject: Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP > > Hello Alexey, > > and for that reason we should do it! Can't Wez simply apply this? > > marcus > > Sunday, December 16, 2007, 3:22:40 PM, you wrote: > > > On 12/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > >> I think the problem there is that this syntax wouldn't support > external > >> variables, and without them there's not much difference between that > and > >> create_function. > > > The difference is, that it is compile-time and create_function is > run-time > > >> troels knak-nielsen wrote: > >> > What was the conclusion on Wez' patch from march [1]? The > discussion > >> > seemed to steer a bit off, on the discussion of scoping rules, but > is > >> > there any reason _not_ to implement Wez' patch in HEAD? > >> > Even if it doesn't entirely replace create_function, it would be > nice > >> > to have as a compile-time alternative. > >> > > >> > [1] http://groups.google.com/group/mailing.www.php- > dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de > >> > > >> > >> -- > >> Stanislav Malyshev, Zend Software Architect > >> [EMAIL PROTECTED] http://www.zend.com/ > >> (408)253-8829 MSN: [EMAIL PROTECTED] > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > -- > > Alexey Zakhlestin > > http://blog.milkfarmsoft.com/ > > > > > Best regards, > Marcus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello Alexey, and for that reason we should do it! Can't Wez simply apply this? marcus Sunday, December 16, 2007, 3:22:40 PM, you wrote: > On 12/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: >> I think the problem there is that this syntax wouldn't support external >> variables, and without them there's not much difference between that and >> create_function. > The difference is, that it is compile-time and create_function is run-time >> troels knak-nielsen wrote: >> > What was the conclusion on Wez' patch from march [1]? The discussion >> > seemed to steer a bit off, on the discussion of scoping rules, but is >> > there any reason _not_ to implement Wez' patch in HEAD? >> > Even if it doesn't entirely replace create_function, it would be nice >> > to have as a compile-time alternative. >> > >> > [1] >> > http://groups.google.com/group/mailing.www.php-dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de >> > >> >> -- >> Stanislav Malyshev, Zend Software Architect >> [EMAIL PROTECTED] http://www.zend.com/ >> (408)253-8829 MSN: [EMAIL PROTECTED] >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 16, 2007 8:56 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > I don't see how it'd help anything in debugging. Presumably, a stack trace would now contain file and line number. > That's not binding. But the problem is, seeing this, one expects > closure. And it's no closure. One might expect that, coming from a language with static scope. Then again, one would also expect global variables in that event. I don't really see this as a huge show stopper. My experience from Javascript (Which probably is the language, that most PHP'ers are likeable to have met anonymous functions in) is, that lesser experienced programmers, are often surprised by static scope. Even if they have used Javascript for a while, they have just assumed, that it was global variables. I think the majority of the users won't miss the feature and those who do, will be able to appreciate why it isn't there. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > > Actually it's the opposite. With create_function, you can bind > > variables, by marshalling them to a string and embed them in the > > That's not binding. But the problem is, seeing this, one expects > closure. And it's no closure. Well, documentation can include the following written using large font: Warning: This is not a closure. PHP doesn't have native means for nested contexts. This construct is just another way of creating usual function during compile-time. (for creating functions in run-time see create_function) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hi,
Am Montag, den 17.12.2007, 08:44 +0100 schrieb Lars Strojny:
[...]
> Maybe deprecating create_function() and allowing something like that
> would be a way to go?
> $func = function($arg) {
>return $arg;
> }
What a stupid and useless remark. Ignore me, sorry.
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hi,
Am Sonntag, den 16.12.2007, 11:56 -0800 schrieb Stanislav Malyshev:
> > Actually it's the opposite. With create_function, you can bind
> > variables, by marshalling them to a string and embed them in the
>
> That's not binding. But the problem is, seeing this, one expects
> closure. And it's no closure.
Maybe deprecating create_function() and allowing something like that
would be a way to go?
$func = function($arg) {
return $arg;
}
As it is compile time, the issue with Op-Code caches would/should go
away.
cu, Lars
--
Lars Strojny
Senior Software Developer
Neu.de GmbH
Wesselinger Strasse 28
50999 Köln
Eingetragen beim Amtsgericht Köln, HRB 61021
Geschäftsführer: Sven Jan Arndt, Christian Dornhoff
Telefon: 02236-48010-21
Fax: 02236-48010-01
Mobil: 0177-3058654
E-Mail: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Actually it's the opposite. With create_function, you can bind variables, by marshalling them to a string and embed them in the That's not binding. But the problem is, seeing this, one expects closure. And it's no closure. So it's different from create_function, in that it doesn't allow binding of variables, but I don't see why that should stop us from implementing, considering the benefits it gives in readability and debugging. I don't see how it'd help anything in debugging. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > I think the problem there is that this syntax wouldn't support external > variables, and without them there's not much difference between that and > create_function. The difference is, that it is compile-time and create_function is run-time > troels knak-nielsen wrote: > > What was the conclusion on Wez' patch from march [1]? The discussion > > seemed to steer a bit off, on the discussion of scoping rules, but is > > there any reason _not_ to implement Wez' patch in HEAD? > > Even if it doesn't entirely replace create_function, it would be nice > > to have as a compile-time alternative. > > > > [1] > > http://groups.google.com/group/mailing.www.php-dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de > > > > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Actually it's the opposite. With create_function, you can bind variables, by marshalling them to a string and embed them in the function-definition. With a static syntax, this isn't possible. However, this is only a problem, when you need to bind variables, which isn't always the case and even then, there are other ways to bind variables in runtime. So it's different from create_function, in that it doesn't allow binding of variables, but I don't see why that should stop us from implementing, considering the benefits it gives in readability and debugging. -- troels On Dec 16, 2007 7:57 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > I think the problem there is that this syntax wouldn't support external > variables, and without them there's not much difference between that and > create_function. > > > troels knak-nielsen wrote: > > What was the conclusion on Wez' patch from march [1]? The discussion > > seemed to steer a bit off, on the discussion of scoping rules, but is > > there any reason _not_ to implement Wez' patch in HEAD? > > Even if it doesn't entirely replace create_function, it would be nice > > to have as a compile-time alternative. > > > > [1] > > http://groups.google.com/group/mailing.www.php-dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de > > > > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
I think the problem there is that this syntax wouldn't support external variables, and without them there's not much difference between that and create_function. troels knak-nielsen wrote: What was the conclusion on Wez' patch from march [1]? The discussion seemed to steer a bit off, on the discussion of scoping rules, but is there any reason _not_ to implement Wez' patch in HEAD? Even if it doesn't entirely replace create_function, it would be nice to have as a compile-time alternative. [1] http://groups.google.com/group/mailing.www.php-dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Sun, March 18, 2007 7:30 pm, Wez Furlong wrote: > I found another flaw; when used in a loop it keeps trying to declare > the same function over and over. I think this is because the > ZEND_DECLARE_FUNCTION opcode is emitted as part of the arg list > building op sequence. > > I'm poking to find an elegant way to fix that. Would the function body/arglist be allowed to change based on the loop data? [shudder] It's starting to sound like Lisp :-) Though I guess if you need anonymous functions, you probably need them with varying bodies as well. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Also, I would love to see this in PHP, at the very least it would negate the argument of those who say PHP doesn't support anonymous functions. This argument is false in any case, since create_function exists and this implementation is other way to write create_function :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Sun, Mar 18, 2007 at 08:48:31PM -0400, Wez Furlong wrote: > Updated patch at http://pastebin.ca/400952 This is interesting. I'm not sure I'll ever use it (I prefer named functions), but it's a purely optional and folks seem to want something like this. One comment on the patch itself: static unsigned int anon_count; I think you should provide an initial value (0?) for this static counter. Also, you should protect against wrap-around (which, while improbably, is possible). Alternatively, you could change the anonymous function naming scheme to something like __zend_anon_FILE_LINE_COLUMN, but that could be an unnecessary waste of string memory. -- Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello Wez, interesting solution. Nice work:-) Monday, March 19, 2007, 1:48:31 AM, you wrote: > Updated patch at http://pastebin.ca/400952 > Not 100% sure if my hack in zend_compile.c is righteous, but it > doesn't seem too far wrong. > --Wez. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello Gwynne,
Monday, March 19, 2007, 3:13:28 AM, you wrote:
> On Mar 18, 2007, at 9:30 PM, Wez Furlong wrote:
>> Your nitpicking happens to be wrong ;-)
>>
>> sizeof("string constant") is the "same" as strlen("string constant")
>> +1, but is resolved at compile time, so we use sizeof("string
>> constant")-1 to get a compile time evaluated strlen(). This trick
>> is used throughout the PHP internals.
> Ah. I've never seen it used that way before; I apologize for my
> ignorance :). In my experience, sizeof() on a character constant
> would evaluate as sizeof( const char * const ).
Actually it is not a "const char *" here. Instead the language generates
a "const char[]" which works asexpected.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Mar 18, 2007, at 9:30 PM, Wez Furlong wrote:
Your nitpicking happens to be wrong ;-)
sizeof("string constant") is the "same" as strlen("string constant")
+1, but is resolved at compile time, so we use sizeof("string
constant")-1 to get a compile time evaluated strlen(). This trick
is used throughout the PHP internals.
Ah. I've never seen it used that way before; I apologize for my
ignorance :). In my experience, sizeof() on a character constant
would evaluate as sizeof( const char * const ).
On Mar 18, 2007, at 9:27 PM, Gwynne wrote:
Updated patch at http://pastebin.ca/400952
Not 100% sure if my hack in zend_compile.c is righteous, but it
doesn't seem too far wrong.
74. + if (!memcmp(opline-
>op2.u.constant.value.str.val, "__zend_anon_", sizeof
("__zend_anon_")-1)) {
Pardon my nitpicking, but shouldn't this be:
74. + if (!memcmp(opline-
>op2.u.constant.value.str.val, "__zend_anon_", strlen
("__zend_anon_")-1)) {
Also, a strong +1 for this patch, I'd love to see this support in
PHP.
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Your nitpicking happens to be wrong ;-)
sizeof("string constant") is the "same" as strlen("string constant")
+1, but is resolved at compile time, so we use sizeof("string
constant")-1 to get a compile time evaluated strlen(). This trick is
used throughout the PHP internals.
--Wez.
On Mar 18, 2007, at 9:27 PM, Gwynne wrote:
On Mar 18, 2007, at 8:48 PM, Wez Furlong wrote:
Updated patch at http://pastebin.ca/400952
Not 100% sure if my hack in zend_compile.c is righteous, but it
doesn't seem too far wrong.
74. + if (!memcmp(opline-
>op2.u.constant.value.str.val, "__zend_anon_", sizeof
("__zend_anon_")-1)) {
Pardon my nitpicking, but shouldn't this be:
74. + if (!memcmp(opline-
>op2.u.constant.value.str.val, "__zend_anon_", strlen
("__zend_anon_")-1)) {
Also, a strong +1 for this patch, I'd love to see this support in PHP.
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Mar 18, 2007, at 8:48 PM, Wez Furlong wrote:
Updated patch at http://pastebin.ca/400952
Not 100% sure if my hack in zend_compile.c is righteous, but it
doesn't seem too far wrong.
74. + if (!memcmp(opline-
>op2.u.constant.value.str.val, "__zend_anon_", sizeof
("__zend_anon_")-1)) {
Pardon my nitpicking, but shouldn't this be:
74. + if (!memcmp(opline-
>op2.u.constant.value.str.val, "__zend_anon_", strlen
("__zend_anon_")-1)) {
Also, a strong +1 for this patch, I'd love to see this support in PHP.
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
> So, the question is, do we want this in PHP? yes, please. Anonymous function declaration is one of the things I've always loved in Ruby and JavaScript - I for one would _love to see this_ in php. -- Jim R. Wilson (jimbojw) On 3/18/07, Wez Furlong <[EMAIL PROTECTED]> wrote: I found another flaw; when used in a loop it keeps trying to declare the same function over and over. I think this is because the ZEND_DECLARE_FUNCTION opcode is emitted as part of the arg list building op sequence. I'm poking to find an elegant way to fix that. --Wez. On Mar 18, 2007, at 7:41 PM, Wez Furlong wrote: > You can find my prototype patch at http://pastebin.ca/400871 > (against PHP_5_2) > There's one minor flaw in my implementation for ZTS enabled systems > (just need to move the anon function counter into CG() to solve that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
