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
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
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,
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
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
(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:
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
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,
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:
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
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
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
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
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,
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
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
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
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
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
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
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
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
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,
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?
--
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.
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
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
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
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
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
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
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,
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
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
:[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
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]
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
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)
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
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
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
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
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
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) {
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
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
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
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
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
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
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
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
Hey, thanks, I was researching this exact same thing. You make it appear much
easier than it is. You've just saved me many months, weeks, and hours trying to
figure out how to mess with the internals of the Zend Engine. For that, I am
most grateful.
Also, I would love to see this in PHP, at
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:
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
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
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,
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
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.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
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,
61 matches
Mail list logo
