--- Jim Wilson [EMAIL PROTECTED] wrote:
Lexical anonymous functions would be enough for me. If these proposed
lexical anonymous functions could automagically bind themselves
to an instance's $this when called from within an object's scope (so as to
act
as virtual methods), that would be
--- Richard Lynch [EMAIL PROTECTED] wrote:
On Thu, March 22, 2007 8:09 am, Christian Schneider wrote:
Plain old google brought up:
http://groovy.codehaus.org/Martin+Fowler's+closure+examples+in+Groovy
among other hits (Groovy syntax should be easy enough to follow).
He said real-life
Lexical anonymous functions would be enough for me. If these proposed
lexical anonymous functions could automagically bind themselves
to an instance's $this when called from within an object's scope (so as to
act
as virtual methods), that would be grand.
I agree - I don't need closures, but
Sorry buddy - thought I was replying to the whole group :(
-- Jim
On 3/23/07, Jim Wilson [EMAIL PROTECTED] wrote:
Lexical anonymous functions would be enough for me. If these proposed
lexical anonymous functions could automagically bind themselves
to an instance's $this when called from
Hi,
On 3/21/07, Richard Lynch [EMAIL PROTECTED] wrote:
I think solving the common need for 99% of the people with a nice
simple clean anonymous function is PHP way.
Right. But then those people add 2 + 2 and get frustrated because they
can't do the obvious ;)
If somebody has a real-life
Michael Walter wrote:
Right. But then those people add 2 + 2 and get frustrated because they
can't do the obvious ;)
I find it all but obvious to being able to use non-local, non-global
variables in PHP. It's one of the main PHP points IMHO that a variables
is either local or explicitely
Hi,
On 3/22/07, Christian Schneider [EMAIL PROTECTED] wrote:
Michael Walter wrote:
Right. But then those people add 2 + 2 and get frustrated because they
can't do the obvious ;)
I find it all but obvious to being able to use non-local, non-global
variables in PHP. It's one of the main PHP
Michael Walter wrote:
I find it all but obvious to being able to use non-local, non-global
variables in PHP. It's one of the main PHP points IMHO that a variables
is either local or explicitely accessed through $_GLOBALS (or super
globals). It gives me a warm and fuzzy feeling that I know
On 22/03/07, Christian Schneider [EMAIL PROTECTED] wrote:
If somebody has a real-life demonstrated NEED for the
closures/scoping, by all means, bring it up.
Plain old google brought up:
http://groovy.codehaus.org/Martin+Fowler's+closure+examples+in+Groovy
among other hits (Groovy syntax
function sort_by_key($key) {
For the record, I do like this syntax, but it COULD be rewritten using
current practices (see below).
class SortByKey {
public $key;
public function __construct($key) {
$this-key = $key;
}
public function do($a, $b) {
if ($a[$this-key] $b[$this-key])
On 3/22/07, Christian Schneider [EMAIL PROTECTED] wrote:
Michael Walter wrote:
Which seems to fit Andi's $_SCOPE proposal.
Yes, but is a point against a real closure proposal.
I think the defining property of a real closure proposal is having
the lexical scope available.
So I guess we both
On 3/22/07, Sean Coates [EMAIL PROTECTED] wrote:
That said, I like the idea of a first class callable object.
For the example above, doing this:
class SortByKey implements Callable {}
Note that this is what Java did since day one (it was thought that
anonymous inner classes were good enough).
Michael Walter wrote:
A simple real-life example is:
function pick($member)
{
return create_function('$x', 'return $x-'.$member.';');
}
which could be used e.g. in
array_map(pick('age'), $people).
Arguably, in this case you could as well write:
array_map(function($p) {return
On 22/03/07, Sean Coates [EMAIL PROTECTED] wrote:
function sort_by_key($key) {
For the record, I do like this syntax, but it COULD be rewritten using
current practices (see below).
I know, and it can be done without typing so much:
class SortByKey {
function __call($name, $a) {
if
For the record, I do like this syntax, but it COULD be rewritten using
current practices (see below).
That's a good point - actually most uses of closures could be with some
effort rewritten as classes. The difference would be that in case of
closures, closure chooses which parts of context
On Thu, March 22, 2007 8:09 am, Christian Schneider wrote:
Plain old google brought up:
http://groovy.codehaus.org/Martin+Fowler's+closure+examples+in+Groovy
among other hits (Groovy syntax should be easy enough to follow).
He said real-life examples (-:C
I said real-life NEED, as in, I
So does this mean that the patch would be included even in its somewhat broken
state? Just don't allow it in loops or warn when it is or access to outside
scope variables.
I need to get VLD working on Windows to see what the fuss is all about. I
thought everything is compiled to oplines, if
Err, Pseudo-oplines, but since I don't exactly know anything about PHP
opcodes, I'm just pulling this stuff out of my ass.
CREATE_FUNCTION test
CREATE_FUNCTION zend_anon_0
RET_VAL 0
END_FUNCTION
END_FUNCTION
CALL 'test'
ASSIGN $0, $valuefunction
It looks like you misunderstand how the
Yes, with whipped cream on top.
-Andrei
On Mar 18, 2007, at 4:41 PM, Wez Furlong wrote:
So, the question is, do we want this in PHP?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I've been wanting a true first-class callable type for a while.
-Andrei
On Mar 19, 2007, at 5:02 PM, Wez Furlong wrote:
The second possibility would be to make a first-class callable zval
type which stores that information in the return value from the
function declaration. The callable
of the function. Again, this would be created based on the $_SCOPES
fixup information, and again, $_SCOPES['i'] would be rewritten as
simply $i in the op_array.
So the funcs array might look like this is var_dump()'d:
0 = callable('__anon_0', array('i' = 0)),
1 = callable('__anon_0',
You need the callable type to store the closure information.
Either that, or you need to store it in the op_array, which is bad
because you don't know when you can free that closure state, so you
have to carry it around for the rest of the request.
I agree about $_SCOPES['foo']. I'm
What if I doo $a = _SCOPES, $$a[$foo]?
FWIW, this doesn't work with the other superglobals (in function context):
[EMAIL PROTECTED]:~$ php -r '$_GET[foo] = bar; function baz() { $get =
_GET; return ${$get}[foo]; } $get = _GET; echo ${$get}[foo],
baz(), \n;'
bar
Notice: Undefined variable: _GET
Either that, or you need to store it in the op_array, which is bad
because you don't know when you can free that closure state, so you have
to carry it around for the rest of the request.
Well, this is a strong argument indeed. However adding new zval type is
a big step which adds complexity
FWIW, this doesn't work with the other superglobals (in function context):
[EMAIL PROTECTED]:~$ php -r '$_GET[foo] = bar; function baz() { $get =
_GET; return ${$get}[foo]; } $get = _GET; echo ${$get}[foo],
baz(), \n;'
bar
Notice: Undefined variable: _GET in Command line code on line 1
(this is
Am 20.03.2007 um 15:24 schrieb Daniel Rozsnyo:
A function with a name is no longer anonymous ;)
I am not suggesting that there be a name.
I am suggesting that the reserved keyword for an anonymous function
should not be 'function', the same as a normal function.
I don't have anything against
what about lambda, like in Python?
To most people without CS theory background lambda does not tell
anything, to people that have this background lambda reminds of LISP -
and I'm not sure this is better :)
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Am 20.03.2007 um 23:42 schrieb Stanislav Malyshev:
what about lambda, like in Python?
To most people without CS theory background lambda does not tell
anything, to people that have this background lambda reminds of
LISP - and I'm not sure this is better :)
Excellent! That means people
Stanislav Malyshev wrote:
FWIW, this doesn't work with the other superglobals (in function
context):
[EMAIL PROTECTED]:~$ php -r '$_GET[foo] = bar; function baz() { $get =
_GET; return ${$get}[foo]; } $get = _GET; echo ${$get}[foo],
baz(), \n;'
bar
Notice: Undefined variable: _GET in Command
On Mon, March 19, 2007 11:59 pm, Andi Gutmans wrote:
There are various ways to go about implementing this. While reading
your
email I've had another couple of ideas incl. some funky parameter
passing games. All these ideas are legit and have pros/cons but what's
most important is actually
$_SCOPE doesn't need to be that special... It can just be an object with
overloaded array access... Whenever a dim is fetched for that object,
check current_execute_data-prev-symbol_table for the variable and
return that.
Once again - current_execute_data-prev at *closure runtime* has
On Tue, 2007-03-20 at 19:02 -0500, Richard Lynch wrote:
Though that will probably end up with a bunch of scripters using
out-of-scope vars with no clue what they just did and how morally
wrong it was to use an intentionally undocumented feature.
Without the right tool, the data needs will be
Stanislav Malyshev wrote:
$_SCOPE doesn't need to be that special... It can just be an object
with overloaded array access... Whenever a dim is fetched for that
object, check current_execute_data-prev-symbol_table for the
variable and return that.
Once again - current_execute_data-prev at
On 03/19/2007 02:41 AM, Wez Furlong wrote:
We've been daydreaming about the ability to do something like this in
PHP:
I don't have any objections, the only requirement from me is that it should be
covered by tests as much as possible.
So I would like to encourage people to write tests to
Wez Furlong wrote:
So, the question is, do we want this in PHP?
Yes, please. (It might even make my userland implementation of of CLOS-
style generic functions easier.)
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD
Well, making it work makes this thing closure. Otherwise it's just a
nice way to save a couple of keystrokes :) Not to diminish your work,
but there's a danger people would think it is closure because it looks
like one (i.e., in other languages closures look exactly this way, e.g.
If the answer is New, then this could be compiled at.. well,
compile-time, not at execute time. That could be even more interesting.
If it would create anonymous function compile-time, it would be a big
advantage to Wez's patch because then this function could be cached.
Thinking about this,
If it would create anonymous function compile-time, it would be a big
advantage to Wez's patch because then this function could be cached.
Thinking about this, maybe it is the reason enough to do this even if
it's not real closure.
On mulling this over a bit more, other than quick one-off
I've been thinking about this on and off today too.
Something along the lines of the following is more in the PHP spirit:
$ver = phpversion();
$fancyVer = function () { lexical $ver; return PHP $ver; };
Where lexical is a keyword that means inherit this variable from
the current lexical
If we can solve the scoping problem (perhaps via references as you
mentioned), then lexical (or another keyword, to be debated endlessly
for months, whose name-debate will delay the implementation of this
functionality, but I digress...) seems like a good solution to grabbing
scope, and fits the
I've been thinking about this on and off today too.
Something along the lines of the following is more in the PHP spirit:
$ver = phpversion();
$fancyVer = function () { lexical $ver; return PHP $ver; };
Where lexical is a keyword that means inherit this variable from the
current lexical scope.
On Sun, March 18, 2007 6:41 pm, Wez Furlong wrote:
We've been daydreaming about the ability to do something like this in
PHP:
$data = array(zoo, orange, car, lemon, apple);
usort($data, function($a, $b) { return strcmp($a, $b); });
var_dump($data); # data is sorted alphabetically
I'd LOVE
On Mon, 2007-03-19 at 13:15 -0700, Stanislav Malyshev wrote:
I've been thinking about this on and off today too.
Something along the lines of the following is more in the PHP spirit:
$ver = phpversion();
$fancyVer = function () { lexical $ver; return PHP $ver; };
Where lexical is a
On Mon, 2007-03-19 at 15:20 -0500, Richard Lynch wrote:
On Sun, March 18, 2007 6:41 pm, Wez Furlong wrote:
We've been daydreaming about the ability to do something like this in
PHP:
$data = array(zoo, orange, car, lemon, apple);
usort($data, function($a, $b) { return strcmp($a, $b); });
On Mar 19, 2007, at 4:15 PM, Stanislav Malyshev wrote:
How this is going to work? Variables are not interpreted by the
compiler now...
Well, the compiler would make a list of variables names to import and
store those in the zend_function structure. Then at the time the
function is
On Mon, March 19, 2007 3:35 pm, Robert Cummings wrote:
On Mon, 2007-03-19 at 15:20 -0500, Richard Lynch wrote:
On Sun, March 18, 2007 6:41 pm, Wez Furlong wrote:
We've been daydreaming about the ability to do something like this
in
PHP:
$data = array(zoo, orange, car, lemon, apple);
What about just having a function that allows retrieving variables from
the parent scope?
mixed seek_var( $name [, $levels=1, [ $startLevel=0 ] ] )
How you are going to know where parent scope is? It can even be not
existing anymore, or can be separated by any number of parameter
Well, the compiler would make a list of variables names to import and
store those in the zend_function structure. Then at the time the
function is bound (in response to a DECLARE_FUNCTION opcode), the
variable reference could be fixed up in the same way that global is
handled.
Global is not
On Mon, 2007-03-19 at 13:59 -0700, Stanislav Malyshev wrote:
What about just having a function that allows retrieving variables from
the parent scope?
mixed seek_var( $name [, $levels=1, [ $startLevel=0 ] ] )
How you are going to know where parent scope is? It can even be not
I guess I was primarily thinking in the context of the anonymous
function being defined in your previous example. As such the parent
scope is known (or at least can be expected), unless (unknown to me)
It is known in compile-time. But functions are not called in
compile-time. And in run-time,
I think the anonymous name having metadata about the __FILE__ __LINE__
__COLUMN__ would be pretty nifty for error messages and debuggers...
I'm a bit tired of seeing Error: blah blah in Unknown on line: 0
personally. :-)
This presumes somebody would take the effort to de-construct that
metadata
My implementation preserves this information.
--Wez.
On Mar 19, 2007, at 5:26 PM, Richard Lynch wrote:
I think the anonymous name having metadata about the __FILE__ __LINE__
__COLUMN__ would be pretty nifty for error messages and debuggers...
I'm a bit tired of seeing Error: blah blah in
On Mon, March 19, 2007 2:33 pm, Wez Furlong wrote:
I've been thinking about this on and off today too.
Something along the lines of the following is more in the PHP spirit:
$ver = phpversion();
$fancyVer = function () { lexical $ver; return PHP $ver; };
Where lexical is a keyword that means
regardless. As in my proposal, the seek could search all the way up to
the top in which case the $rev would be found if it had been defined as
The top of *what*? Anonymous function could be called from global scope too.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]
I'm not arguing the preservation of the exact value of $rev when the
anonymous function was created (as would be the case with a closure).
I'm thinking of the variable being whatever is defined in the parent
regardless. As in my proposal, the seek could search all the way up to
the top in
We could compile the anonymous function at compile-time but leave
placeholders which need to be fixed-up when at run-time the actual
closure is created. For this purpose we could introduce a new magical
variables $_SCOPE[var] which references the current $var during fixup
time.
So here's an
So what this does is compile the anonymous function at compile-time,
but when this line is executed (note, this line of code should also be
reached during execution), then we do the fix-up for $_SCOPE variables.
Yes, this is basically what Wez was proposing I guess. This would
require new
Stanislav Malyshev wrote:
Thoughts?
This might work, still not sure if we really want that in PHP. On one
side, it's cool, on other side closures can develop into a very messy
code :)
Yeah well .. for the single task of callbacks they are great and prevent
a lot of messiness .. I think
Subject: Re: [PHP-DEV] PATCH: anonymous functions in PHP
Stanislav Malyshev wrote:
Thoughts?
This might work, still not sure if we really want that in
PHP. On one
side, it's cool, on other side closures can develop into a
very messy
code :)
Yeah well .. for the single task
On Mon, March 19, 2007 4:55 pm, Stanislav Malyshev wrote:
You have to have a pretty esoteric function to need that kind of
scope
control, no?
Depends on your background. Some people consider LISP intuitive
language
:) And if you work with Javascript, you probably would be doing it
daily
-
Can't you just take the body of create_function with the syntax of
the patch, and marry those two?
Well, that'd be a bit hard since the whole difference is that
create_function is runtime (thus having access to run-time values) while
anon-func we are trying to do here is compile-time (at
Can't you just take the body of create_function with the syntax of
the patch, and marry those two?
I already explained why this can't work, in this very thread. At least
not without hacking { and } to work (mostly) like in this context.
How does the current create_function handle this same
On Mon, March 19, 2007 5:33 pm, Stanislav Malyshev wrote:
Can't you just take the body of create_function with the syntax of
the patch, and marry those two?
Well, that'd be a bit hard since the whole difference is that
create_function is runtime (thus having access to run-time values)
while
On Mon, 2007-03-19 at 17:53 -0400, Sean Coates wrote:
I'm not arguing the preservation of the exact value of $rev when the
anonymous function was created (as would be the case with a closure).
I'm thinking of the variable being whatever is defined in the parent
regardless. As in my
Richard Lynch wrote:
I'd be perfectly happy if PHP's anonymous functions had the nice
syntax and no funky weird stuff about closure, a la
eval/create_function, personally.
While the discussion about closures and how to emulate them was
interesting I think Richard hits the nail on the head.
I've been thinking about this in the car, and it won't quite work as-is.
Here's a contrived example:
$funcs = array();
for ($i = 0; $i 10; $i++) {
$funcs[] = function() { return $_SCOPE['i']; };
}
Here I'm assuming that $_SCOPE takes a copy of $i during fixup.
The problem here is that the
--- Sean Coates [EMAIL PROTECTED] wrote:
I'm not arguing the preservation of the exact value of $rev when the
anonymous function was created (as would be the case with a closure).
I'm thinking of the variable being whatever is defined in the parent
regardless. As in my proposal, the seek
Cc: Stas Malyshev; Robert Cummings; Sean Coates;
internals@lists.php.net
Subject: Re: [PHP-DEV] PATCH: anonymous functions in PHP
I've been thinking about this in the car, and it won't quite
work as-is.
Here's a contrived example:
$funcs = array();
for ($i = 0; $i 10; $i++) {
$funcs
We've been daydreaming about the ability to do something like this in
PHP:
$data = array(zoo, orange, car, lemon, apple);
usort($data, function($a, $b) { return strcmp($a, $b); });
var_dump($data); # data is sorted alphabetically
In the past, people have been told to use the travesty that is
On Mon 19 Mar 2007, at 19 Mar 00:41, Wez Furlong wrote:
So, the question is, do we want this in PHP?
yes, please.
Jan
--
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
$data = array(zoo, orange, car, lemon, apple);
usort($data, function($a, $b) { return strcmp($a, $b); });
var_dump($data); # data is sorted alphabetically
What happens if you do this:
$data = array(zoo, orange, car, lemon, apple);
$rev = 1;
usort($data, function($a, $b) { return
I didn't make it do anything fancy with scoping; it would make the
implementation more complicated, and wouldn't fit so well with the
way that scoping works in PHP, in that you need to explicitly
reference the global scope to break out of your function scope.
It would be cool if the
I didn't make it do anything fancy with scoping; it would make the
implementation more complicated, and wouldn't fit so well with the way
that scoping works in PHP, in that you need to explicitly reference the
global scope to break out of your function scope.
It would be cool if the lexical
73 matches
Mail list logo
