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 wr
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
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 ind
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 d
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
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
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
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
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.
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 o
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
--
Alexe
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,-let
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" d
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, n
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
> spreadi
(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
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 coul
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 o
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:
> 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
>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 demo
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 shoul
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 us
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
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:
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 fo
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?
--
Sta
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 u
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 t
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 def
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 us
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) {
r
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(
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 shou
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 wron
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 numer
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 ma
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)
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
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]
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 wi
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
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.
We
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
Desc
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
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
bind
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-t
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
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 di
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
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 Malysh
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:
s
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 - P
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
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 us
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
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
("__ze
> 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
59 matches
Mail list logo
