Hello Stanislav,
Monday, June 30, 2008, 12:20:15 AM, you wrote:
> Hi!
>> * Class::__invoke() to allow functors[1]. The class "Closure" in
>> your proposal should also implement that method to make
>> method_exists() and ext/reflection behave.
>> * Change the behaviour
On Mon, Jun 30, 2008 at 12:41 AM, Lars Strojny <[EMAIL PROTECTED]> wrote:
> Hi Stas,
>
> Am Sonntag, den 29.06.2008, 15:20 -0700 schrieb Stanislav Malyshev:
> [...]
>> If we use this syntax, and $view->escape is not defined, should we
>> call __call or __get?
>
> That's indeed a good question. Call
Hi Stas,
Am Sonntag, den 29.06.2008, 15:20 -0700 schrieb Stanislav Malyshev:
[...]
> If we use this syntax, and $view->escape is not defined, should we
> call __call or __get?
That's indeed a good question. Calling __get() after resolving
$view->escape as a property would break BC. Maybe we would
Hi!
* Class::__invoke() to allow functors[1]. The class "Closure" in
your proposal should also implement that method to make
method_exists() and ext/reflection behave.
* Change the behaviour how method calls are resolved. Method calls
on invokable objects (clo
Hi Christian,
thanks again for your (and Dmitry's) great work on making closures a
part of PHP.
Am Donnerstag, den 26.06.2008, 18:23 +0200 schrieb Christian Seiler:
> * I have *not* added any __invoke() magic to normal objects. This is
> mainly due to the simple reason that adding that woul
Thanks for "static function ()" idea, it's much better and consistent
than "function () use ($this)". I think we should go this way.
Do you see any other issues with the patch?
Thanks. Dmitry.
Alexander Wagner wrote:
On Friday 27 June 2008, Andi Gutmans wrote:
I am not sure I like the idea
See below:
> -Original Message-
> From: Alexander Wagner [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 27, 2008 12:31 PM
> To: internals@lists.php.net
> Cc: Andi Gutmans; Dmitry Stogov; Christian Seiler; Stas Malyshev
> Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures an
On Friday 27 June 2008, Dmitry Stogov wrote:
> 1) Fixed ref/noref issues
Works for me. See attached test 11.
Gesundheit
Wag
--
For sale: baby shoes, never worn.
- flash fiction by Hemingway
--TEST--
Closure test: Closure calls itself
--SKIPIF--
--FILE--
--EXPECT--
3
2
1
0
--TEST--
Closure
On Friday 27 June 2008, Andi Gutmans wrote:
> I am not sure I like the idea of explicit $this.
> [..] If we ever discover this is a huge issue
Implicit unoptimized $this is never going to be a "huge issue", because it is
not badly broken, only sublty.
My crystal ball tells me that the following i
: Christian Seiler
> Cc: php-dev List; Andi Gutmans; Stas Malyshev
> Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
>
> Hi Christian,
>
> I reworked your patch a little bit.
>
> 1) Fixed ref/noref issues
>
> 2) Explicit $this pas
Hi!
I thought about use($this) too. :)
I'll try to implement it in the next version of the patch.
I think implicitly using $this when it's referred to is much better.
$this is very special variable so it deserves special treatment. If we'd
need to spare a couple of bytes for that - that's no
I thought about use($this) too. :)
I'll try to implement it in the next version of the patch.
Thanks. Dmitry.
Alexander Wagner wrote:
> On Friday 27 June 2008, Andi Gutmans wrote:
>> I lean towards the use(...) syntax.
>
> Me too.
>
>>> * I provided a patch variant that only stores $this if $
> Yes, you're right. My solution for this would be:
I can't get this to work, it segfaults for me now when I try to use closures.
Maybe I screwed something up, this is my first Zend-Engine-hackery.
As you agree that the current behaviour is kinda weird, just put the fix in
the next wave of patch
On Friday 27 June 2008, Andi Gutmans wrote:
> I lean towards the use(...) syntax.
Me too.
> > * I provided a patch variant that only stores $this if $this is
> > explicitely used inside a closure [..]
>
> Safest not to take shortcuts. You get yourself into trouble with things
> which will s
On Thursday 26 June 2008 11:23:53 am Christian Seiler wrote:
> Hi Dmitry,
>
> > I'm fine if you'll improve my patch (It's mainly yours :)
>
> I updated my closures RFC: http://wiki.php.net/rfc/closures
> In my eyes, the following questions should be answered:
>
> * Do you want closures in PHP?
>
Hey Christian,
Nice job!
More below:
> -Original Message-
> From: Christian Seiler [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2008 9:24 AM
> To: Dmitry Stogov
> Cc: php-dev List; Andi Gutmans; Stas Malyshev
> Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures an
Hi!
I see exactly one problem with the patch, which is that the above script
shouldn't work without "use (&$i)".
I find it counterintuitive that the creation of the lambda creates a copy of
$i, but all invocations of $lambda use a reference to the same $i.
For n calls to $lambda, there are only
Hi Marcus,
I like the new ability to reference if wanted. But then I don't like
references at all.
As I said: Without reference support, you can't call it closures.
Closures must per definition have the possibility to change the values
of used variables in the parent scope - and the only sensi
> * I added tests (Zend/tests/closures_*.phpt) that ensure the correct
> behaviour of closures.
I'd like to propose an additional test to ensure closures can all themselves:
Expected output:
3
2
1
3
I see exactly one problem with the patch, which is that the above script
shouldn't work wi
Hello Sebastian,
ok, even though I just wrote differently. It appears to me, after reading
the rest of the thread, that I shouuld maybe give in and favor a 5.4
instead.
marcus
Wednesday, June 25, 2008, 10:42:50 AM, you wrote:
> Lukas Kahwe Smith wrote:
>> I am very sure we will see a 5.4. The
Hello Christian,
Thursday, June 26, 2008, 6:23:53 PM, you wrote:
> Hi Dmitry,
>> I'm fine if you'll improve my patch (It's mainly yours :)
> I updated my closures RFC: http://wiki.php.net/rfc/closures
> I have based my new version of the patch on yours (Dmitry), but I made
> some changes to th
Hi Dmitry,
I'm fine if you'll improve my patch (It's mainly yours :)
I updated my closures RFC: http://wiki.php.net/rfc/closures
I have based my new version of the patch on yours (Dmitry), but I made
some changes to that:
* Objects instead of resources are used, two new files
zend_closur
On Jun 26, 2008, at 4:06 AM, Lukas Kahwe Smith wrote:
Now, upon execution of the code containing the closure, the new
opcode
just copies the zend_function structure into a copy, registers that
copy
as a resource and returns that resource. As soon as the resource is
garbage collected (or expli
On 18.06.2008, at 14:17, Christian Seiler wrote:
Now, upon execution of the code containing the closure, the new opcode
just copies the zend_function structure into a copy, registers that
copy
as a resource and returns that resource. As soon as the resource is
garbage collected (or explicitl
Lukas Kahwe Smith wrote:
I am very sure we will see a 5.4. There is also the traits patch
that is more or less ready
And the switch from bison to lemon is also on the agenda for PHP 5.4.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7
On 24.06.2008, at 18:55, Wez Furlong wrote:
I'm +1 for inclusion of this into the next release of PHP (post 5.3),
and like Andrei, would love there to be a first class callable type
for dynamic invocation of "regular" functions and methods.
Just a side note about the timing. I know some peop
Just to chime in on this thread; I like your implementation and (after
reading through all the other comments so far), prefer the lexical
keyword to import variables.
As I've said before, the closure aspect of this is the hardest to gel
into PHP, which deliberately avoids inheriting scopes. Since
On Tue, Jun 24, 2008 at 9:19 AM, Kalle Sommer Nielsen <[EMAIL PROTECTED]> wrote:
> Another subject I would like to see now the closures has been brought up
> again
> is, how about adding type hinting in method/function prototypes:
>
> function call(function $callback)
> {
>$callback();
> }
Hey
How are we going to deal with Closures in class properties, like:
class PHP
{
public $closure;
public function __construct($callback)
{
$this->closure = $callback;
}
public function closure()
{
echo 'PHP::closu
Hi Stas,
Am Montag, den 23.06.2008, 10:56 -0700 schrieb Stanislav Malyshev:
> What do you think?
I really love that idea. Real Functors¹ in PHP, great!
1) http://en.wikipedia.org/wiki/Function_object
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Hi!
Hmm, seems like a good idea. If nobody objects in the next few days,
I'll rewrite my patch to use objects instead of resources. What class
name do you suggest?
While we are at it maybe even having special standard handler
(__invoke?) that could be also used by objects created by reflectio
Hi Alex, hi Larry,
Am Freitag, den 20.06.2008, 16:33 +0200 schrieb Alexander Wagner:
[...]
> I agree. "use" for both namespaces and closures may not be a good idea.
> Otherwise +1 to this syntax for its low WTF-factor.
> Look like parameters. Behave like parameters.
Probably "reuse" as in "reuse
Hello Dmitry,
Friday, June 20, 2008, 2:19:46 PM, you wrote:
> No it won't.
> Dmitry.
> Lars Strojny wrote:
>> Hi Dmitry, hi Christian,
>>
>> Am Freitag, den 20.06.2008, 15:12 +0400 schrieb Dmitry Stogov:
>>> $func = function ($x, $y) use $a, $b, $c {
>>> }
I really like your style here :-)
W
Hello Stanislav,
Friday, June 20, 2008, 7:44:10 PM, you wrote:
> Hi!
>> As one of the Haskell list denizens commented, is there a potential for
>> memory
>> leakage if lambdas implicitly import $this when defined within an object
> Not really leakage (if refcounts done right) but lifetimes e
On Fri, Jun 20, 2008 at 9:36 PM, Markus Fischer <[EMAIL PROTECTED]> wrote:
> Since some raised issues with the word "lexical", what do people think to
> just re-use the (afaik deprecated) "var" keyword, so we won't need a new
> keyword in the chain.
What exactly is the problem with "lexical"? I fi
Hi!
Since some raised issues with the word "lexical", what do people think
to just re-use the (afaik deprecated) "var" keyword, so we won't need a
new keyword in the chain.
That would be quite confusing IMHO, since JavaScript uses 'var' for the
exact opposite - to declare variables that are l
Since some raised issues with the word "lexical", what do people think to just
re-use the (afaik deprecated) "var" keyword, so we won't need a new keyword in
the chain.
cheers,
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 20 Jun 2008 12:00:07 -0400, Robert Cummings <[EMAIL PROTECTED]> wrote:
>> function foo($a, $b, &$c) global ($d, &$e) {
>> // ...
>> }
>>
>> $myfunc = lambda($a, $b, &$c) lexical ($d, &$e) {
>> // ...
>> }
>>
>> That puts all the information in the declaration line with parallel
> synt
Hi!
As one of the Haskell list denizens commented, is there a potential for memory
leakage if lambdas implicitly import $this when defined within an object
Not really leakage (if refcounts done right) but lifetimes extending
beyond what is expected - i.e. if some instance of closure generate
> I think allowing globals/lexicals to be passed by value doesn't make
> much sense, you could just use a regular parameter for that.
No, that is highly inconvenient when you're doing actual functional
programming with higher order functions and everything.
$i = 1;
$incrementor = lambda ($x) lex
On Fri, 2008-06-20 at 10:50 -0500, Larry Garfield wrote:
> On Fri, 20 Jun 2008 16:33:08 +0200, Alexander Wagner <[EMAIL PROTECTED]>
> wrote:
> > On Friday 20 June 2008, Larry Garfield wrote:
> >> > function ($x, $y) use ($a, $b, &$c) {};
> >>
> >> I am not sure if "use" is the clearest word to use
Larry Garfield escreveu:
> Totally silly idea:
function foo($a, $b, &$c) global ($d, &$e) {
// ...
}
$myfunc = lambda($a, $b, &$c) lexical ($d, &$e) {
// ...
}
That puts all the information in the declaration line with parallel syntax and
semantics, and would even allow both by-val and b
On Friday 20 June 2008, Chris Stockton wrote:
> No one at all thinks:
> function foo($x, $y) use $a, $b, $c {
> }
>
> Looks awkward and a little out of place
It certainly is new and different in PHP, but I don't see a reason why this
should be hard to get used to.
Also, it works for Java exceptio
On Fri, 20 Jun 2008 16:33:08 +0200, Alexander Wagner <[EMAIL PROTECTED]> wrote:
> On Friday 20 June 2008, Larry Garfield wrote:
>> > function ($x, $y) use ($a, $b, &$c) {};
>>
>> I am not sure if "use" is the clearest word to use there (wouldn't
> lexical
>> there make more sense?)
>
> I agree. "
Hi,
I would be fine with requiring an explicit declaration of $this if it helped
avoid memory leaks.
I would propose to always require explicit declaration of $this, even if there
is no memory-leak problem. This would make it easier to distinguish plain
lambdas from closures and would preve
Hello,
No one at all thinks:
function foo($x, $y) use $a, $b, $c {
}
Looks awkward and a little out of place when compared to:
vs
function foo($x, $y) {
lexical $a, $b, $c;
}
Although the fact we have to import variables from the parent scope kinda
stinks and is not typical in closer imple
On Friday 20 June 2008, Larry Garfield wrote:
> > function ($x, $y) use ($a, $b, &$c) {};
>
> I am not sure if "use" is the clearest word to use there (wouldn't lexical
> there make more sense?)
I agree. "use" for both namespaces and closures may not be a good idea.
Otherwise +1 to this syntax for
On 6/20/08, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> It is possible to do it, but I don't see any reason to invest time into
> it. PHP scripts hardly ever use nested functions, and you always can
> access global variables through "global" or $GLOBALS. I don't see, why
> do we need another way
It is possible to do it, but I don't see any reason to invest time into
it. PHP scripts hardly ever use nested functions, and you always can
access global variables through "global" or $GLOBALS. I don't see, why
do we need another way to do the same.
Thanks. Dmitry.
Lars Strojny wrote:
> Hi Dmitr
Hi Dmitry,
Am Freitag, den 20.06.2008, 16:19 +0400 schrieb Dmitry Stogov:
> No it won't.
While I don't want to use it, it might be really confusing to our users
that it works different to closures (because the declaration of
functions and closures looks similar). Are there any internal
limitation
On Friday 20 June 2008, Lenar Lõhmus wrote:
> Hi,
>
> Rodrigo Saboya wrote:
> >> function ($x, $y) ($a, $b, $c) {};
> >
> > This looks better
> >
> >> function ($x, $y) [$a, $b, $c] {};
>
> I think this looks even better:
>
> function ($x, $y) use ($a, $b, &$c) {};
>
> (one could use this synt
No it won't.
Dmitry.
Lars Strojny wrote:
> Hi Dmitry, hi Christian,
>
> Am Freitag, den 20.06.2008, 15:12 +0400 schrieb Dmitry Stogov:
>> $func = function ($x, $y) use $a, $b, $c {
>> }
>
> Will lexical scoping work with normal ("named") functions too?
>
> function foo($x, $y) use $a, $b, $c {
Hi Dmitry, hi Christian,
Am Freitag, den 20.06.2008, 15:12 +0400 schrieb Dmitry Stogov:
>
> $func = function ($x, $y) use $a, $b, $c {
> }
Will lexical scoping work with normal ("named") functions too?
function foo($x, $y) use $a, $b, $c {
}
cu, Lars
signature.asc
Description: Dies ist ein d
Hi Christian,
I'm fine with your suggestion for lexical variables syntax, but I don't
know if we really need brackets around them. For now I changed syntax in
the following way.
$func = function ($x, $y) use $a, $b, $c {
}
According to segfault, I added a check that emits fatal error.
I don't l
Hey
I must say that the lexical keywords makes alot more sense to me which keeps
the syntax readable without making it too cryptic for the unexperinced or new
developer to php.
I think introducing both the lexical keyword and as Andi proposed a
$LEXICAL as
a to the global / $GLOBALS.
Both wa
Hello Stanislav,
Wednesday, June 18, 2008, 5:00:09 PM, you wrote:
> Hi!
>> First: My patch is quite non-intrusive, it only adds things in a few
>> places (new opcode, a few checks). If you only look at the non-generated
> I think it falls into "famous last words" category. While I did not have
Hello Andi,
Thursday, June 19, 2008, 8:44:07 AM, you wrote:
> See below:
>> -Original Message-
>> From: Christian Seiler [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, June 18, 2008 1:14 PM
>> To: php-dev List
>> Subject: Re: [PHP-DEV] [PATCH] [RFC] Clo
Hello Andi,
Wednesday, June 18, 2008, 8:01:34 AM, you wrote:
> Hi Christian,
> This is a very nice piece of work. Definitely addresses a lot of the issues
> we have raised in the past.
> I would like to see such a solution make its way into PHP (see below re:
> timing).
> There are some thing
Hi,
Rodrigo Saboya wrote:
>>
>> function ($x, $y) ($a, $b, $c) {};
>
> This looks better
>
>> function ($x, $y) [$a, $b, $c] {};
I think this looks even better:
function ($x, $y) use ($a, $b, &$c) {};
(one could use this syntax even for traditional functions to
use variable copies/references f
Hi!
Yes, I would rather put it in 5.4 (or whatever the next version) is and
make sure that along with lambdas/closures we have a way of referring to
functions/methods as first-class objects.
Maybe we could make some object handler so that $object($foo) would work
and treat object as "functio
On Friday 20 June 2008, Stanislav Malyshev wrote:
> * A closure must be able to call itself recursively (via a
> higher-order function typically)
> [Check, since you can use variable you assigned closure to inside the
> closure, if I understand correctly]
This is a matter of implementation rather
Hi!
First, a comment from haskell-land:
http://www.haskell.org/pipermail/haskell-cafe/2008-June/044533.html
http://www.haskell.org/pipermail/haskell-cafe/2008-June/thread.html#44379
Thanks for the links, very interesting. Even a couple of comments in the
thread going beyond "PHP sucks" and re
First, a comment from haskell-land:
http://www.haskell.org/pipermail/haskell-cafe/2008-June/044533.html
http://www.haskell.org/pipermail/haskell-cafe/2008-June/thread.html#44379
On Wednesday 18 June 2008, Christian Seiler wrote:
> Frankly, I don't really see a problem with using references. It fit
Hi Dmitry,
First of all: Your patch does really simplify things internally quite a
bit - I like it. I have a few issues though:
The patch shouldn't affect opcode caches and other extensions as it
doesn't change any structures.
I don't see a problem in changing structures for either extensions
Yes, I would rather put it in 5.4 (or whatever the next version) is and
make sure that along with lambdas/closures we have a way of referring to
functions/methods as first-class objects.
-Andrei
Marcus Boerger wrote:
Hello Stanislav,
nicely put but not in agreement with the PHP world. Firs
Dmitry Stogov escreveu:
I don't like "lexical" keyword, because it can be used anywhere in
function (e.q. inside "if" or loop statement), however lexical variables
must be the part of lambda function definition.
I agree with Dmitry: Lexical variables belong to lambda function
definition. It
On Thu, Jun 19, 2008 at 4:37 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> I don't like "lexical" keyword, because it can be used anywhere in function
> (e.q. inside "if" or loop statement), however lexical variables must be the
That does sound wtf-y, indeed. Is that allowed with the global
keyw
I don't like "lexical" keyword, because it can be used anywhere in
function (e.q. inside "if" or loop statement), however lexical variables
must be the part of lambda function definition.
We can think about some better syntax, like
function ($x, $y) ($a, $b, $c) {};
function ($x, $y) [$a, $b,
Hi Dmitry,
As a lowly userspace developer, the | syntax is a bit confusing. If I
see $x, $y | $a, $b, $c, my brain parses it as ($a, ($y | $a), $b, $c),
since , has lower precedence than |. I'd think "syntax error", then
"logical OR", but never "this refers to the variables I want imported to
Hi Christian,
I took a look into your patch and found it too difficult.
So I implemented another patch (attached) which is based on your ideas.
>From user's level of view it does exactly the same except for "lexical"
variables definition. I don't use any new reserver word because every
new reserv
On Thu, Jun 19, 2008 at 8:44 AM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>> >> - In PHP 5, object storage is resources done right. I don't think
>> >> we should be using the resource infrastructure for this
>> >> implementation and would prefer to use the object one. It's better.
>> >> I suggest to
See below:
> -Original Message-
> From: Christian Seiler [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2008 1:14 PM
> To: php-dev List
> Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
>
> Frankly, I don't really see a problem
Hi Andi, Hi Stanislav,
- You mention "global" and "static" as examples of how we do things
today. They are actually not good examples because the binding by
reference which they do has been a real pain over the years. This
is why we introduced the $GLOBALS[] array so that you could also
assign b
On 6/18/08, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Which brings me to another point - how bad would it be if closure's
> lifetime would be limited to parent's lifetime? Of course, this would limit
> some tricks, but would allow some other - like this direct access to
> parent's scope.
t
Hi!
by reference ($GLOBALS["foo"] =& $var). Now that I think of this
example I'd actually prefer to see $LEXICALS[] or something similar
The problem here might be that if we do something like $LEX[$foo] in
runtime, we don't know which parts of parent's scope we need to
preserve. While I like
Hi Christian,
Thanks for the clarifications. This helped a lot and makes me feel very
confident about this implementation. I think this is a very strong proposal.
A few additional things I thought about while taking a closer look:
- You mention "global" and "static" as examples of how we do thin
Hi!
This lookup happens at the time the closure is first declared, and the
value is stored for later use by the closure; the calling scope doesn't
This would work for $var, but what about $$var and various other ways of
indirect variable access?
--
Stanislav Malyshev, Zend Software Architec
Hi,
[I'm going to collect here a bit:]
Stanislav Malyshev wrote:
lexical in the proposal binds to creator's scope, not caller's scope, as
I understood. Anyway, binding to caller's immediate scope doesn't seem
that useful since you could just pass it as a parameter when calling.
Correct and I
On Jun 18, 2008, at 11:01 AM, Stanislav Malyshev wrote:
The Lua interpreter handles this by resolving variable references
as they're made; "someVariable1" is looked up in the closure's
scope and not found, so the interpreter steps out one scope and
looks for it
You may get into a problem her
Hello,
I am curious if is_callable will be able to detect these? Or do we need a
is_lamba, or is_function or something. You may have mentioned it but reading
through I did not notice. I am only curious how to know when someone passed
me one of these. Maybe a type hint would be nice too but that is
Hi!
First: My patch is quite non-intrusive, it only adds things in a few
places (new opcode, a few checks). If you only look at the non-generated
I think it falls into "famous last words" category. While I did not have
time yet to look into the patch in the detail, I have hard time to
believe
Hi!
The Lua interpreter handles this by resolving variable references as
they're made; "someVariable1" is looked up in the closure's scope and
not found, so the interpreter steps out one scope and looks for it
You may get into a problem here - creator's scope may not exist when you
execute
Hi!
1) I am not sure that the current semantics of the "lexical" keyword
is great in all cases. Is the reason why you don't allow by-value
binding so that we don't have to manage more than one lambda instance
per declaration?
First of all: global and static are also used to create references t
Hi!
- I am a little confused about the OOP interaction. How does a function
become a public method of the class?
To clarify: the "public method" ist just the internal representation of
the lambda function and has *nothing* to do with the semantics of
calling the lambda itself. The "method" onl
2008/6/18 Gwynne Raskind <[EMAIL PROTECTED]>:
> On Jun 18, 2008, at 2:36 AM, Alexey Zakhlestin wrote:
>
>> 1) I am not sure that the current semantics of the "lexical" keyword is
>>> great in all cases. Is the reason why you don't allow by-value binding so
>>> that we don't have to manage more tha
On Jun 18, 2008, at 2:36 AM, Alexey Zakhlestin wrote:
1) I am not sure that the current semantics of the "lexical"
keyword is great in all cases. Is the reason why you don't allow by-
value binding so that we don't have to manage more than one lambda
instance per declaration?
by-reference bi
On 6/18/08, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> 1) I am not sure that the current semantics of the "lexical" keyword is
> great in all cases. Is the reason why you don't allow by-value binding so
> that we don't have to manage more than one lambda instance per declaration?
by-reference bi
Hi Christian,
This is a very nice piece of work. Definitely addresses a lot of the issues we
have raised in the past.
I would like to see such a solution make its way into PHP (see below re:
timing).
There are some things I'd like to consider:
1) I am not sure that the current semantics
On Tuesday 17 June 2008, Christian Seiler wrote:
> Hi,
>
> > - I am a little confused about the OOP interaction. How does a function
> > become a public method of the class?
>
> To clarify: the "public method" ist just the internal representation of
> the lambda function and has *nothing* to do wi
Christian Seiler wrote:
> As a followup to the discussion in January, I'd like post a revised
> patch to this list that implements closures and anonymous functions
> in PHP.
Did I miss seeing its phpt tests?
A really thorough test suite might the case for inclusion in PHP 5.3.
Chris
--
Christo
Hi!
I'm not Johannes and I didn't review the proposal in detail yet, but I
think we have enough for 5.3 right now. I'd think we better concentrate
on tying the loose ends and rolling beta out and then moving towards the
release than adding more and more features and never releasing it. 5.3
is
Hi!
nicely put but not in agreement with the PHP world. First we cannot add
a new feature like this in a mini release as it comes with an API change.
And second PHP is not anywhere close so we'd have to do it in a PHP 5.4
and personally I would like to avoid it.
You meant "PHP 6 not anywhere
Hi Markus, hi Stas,
Am Dienstag, den 17.06.2008, 12:19 -0700 schrieb Stanislav Malyshev:
[...]
> I'm not Johannes and I didn't review the proposal in detail yet, but I
> think we have enough for 5.3 right now. I'd think we better concentrate
> on tying the loose ends and rolling beta out and the
Hello Stanislav,
nicely put but not in agreement with the PHP world. First we cannot add
a new feature like this in a mini release as it comes with an API change.
And second PHP is not anywhere close so we'd have to do it in a PHP 5.4
and personally I would like to avoid it.
marcus
Tuesday, Ju
On 6/17/08, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> I'm not Johannes and I didn't review the proposal in detail yet, but I
> think we have enough for 5.3 right now. I'd think we better concentrate on
> tying the loose ends and rolling beta out and then moving towards the
> release than ad
I'm not Johannes and I didn't review the proposal in detail yet, but I
think we have enough for 5.3 right now. I'd think we better concentrate
on tying the loose ends and rolling beta out and then moving towards the
release than adding more and more features and never releasing it. 5.3
is not
Hi!
Johannes, what's your take on this one for 5.3?
I'm not Johannes and I didn't review the proposal in detail yet, but I
think we have enough for 5.3 right now. I'd think we better concentrate
on tying the loose ends and rolling beta out and then moving towards the
release than adding mor
Hello Christian, Johannes,
Tuesday, June 17, 2008, 2:24:01 PM, you wrote:
> Hi Marcus,
> I now have revised my patch to include your suggestions:
> http://www.christian-seiler.de/temp/closures-php-5.3-2008-06-17-2.diff
> The changes to the previous version:
> - \0 at the start of the compil
Hello,
Great patch and a much needed feature. One thing I do not agree with is the
point in the lexical key word, seems it should be natural to inherit the
outer scope. I guess the choice of adding lexical and going slightly against
the grain of typical closure implementations like scheme or ecmas
Hi Marcus,
I now have revised my patch to include your suggestions:
http://www.christian-seiler.de/temp/closures-php-5.3-2008-06-17-2.diff
The changes to the previous version:
- \0 at the start of the compiled lambda function name is dropped.
- lambdas which are class members are now marked
1 - 100 of 111 matches
Mail list logo
