Hi
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
You are trying to take typing way beyond what PHP (or probably any
mainstream dynamic language that exists now) provides. There are
Am 12.10.2012 23:06, schrieb Nikita Popov:
On Fri, Oct 12, 2012 at 10:58 AM, Christian Kaps
christian.k...@mohiva.com wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request $request, Closure $onFound);
}
An implementation of the interface could be as
On Oct 12, 2012 10:59 AM, Christian Kaps christian.k...@mohiva.com
wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request
Hi!
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
You are trying to take typing way beyond what PHP (or probably any
mainstream dynamic language that exists now) provides. There
On Fri, Oct 12, 2012 at 10:58 AM, Christian Kaps
christian.k...@mohiva.com wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request
Hi,
What is the status of this RFC: Closures: Object extension?
https://wiki.php.net/rfc/closures/object-extension
_md
It's been merged in 5.4 branch.
http://svn.php.net/viewvc?view=revisionrevision=316300http://svn.php.net/viewvc?view=revisionrevision=316300
is
the rev I think.
Stas should have more info about that :)
Cheers
Julien.Pauli
On Fri, Jan 6, 2012 at 3:47 PM, Marcello Duarte
On Wed, 11 Aug 2010 14:57:47 +0100, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2010-08-11 at 14:38 +0100, Gustavo Lopes wrote:
I've updated the wiki page for Closures with objects extension with
things that are in Proposal A with modifications but are not
implemented:
I've updated the wiki page for Closures with objects extension with
things that are in Proposal A with modifications but are not implemented:
http://wiki.php.net/rfc/closures/object-extension#status_as_of_august_10_2010
I propose an implementation of closures stored in properties used as
On Wed, 2010-08-11 at 14:38 +0100, Gustavo Lopes wrote:
I've updated the wiki page for Closures with objects extension with
things that are in Proposal A with modifications but are not implemented:
http://wiki.php.net/rfc/closures/object-extension#status_as_of_august_10_2010
I propose an
On Wed, 11 Aug 2010 14:57:47 +0100, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2010-08-11 at 14:38 +0100, Gustavo Lopes wrote:
I've updated the wiki page for Closures with objects extension with
things that are in Proposal A with modifications but are not
implemented:
On Wed, 2010-08-11 at 15:29 +0100, Gustavo Lopes wrote:
* What about allowing properties with function names as
strings or
array($obj_or_class, 'method'), won't that be needed for
being
consistent with local variables?
Well, you cannot do $a = 'phpinfo'; $a(); as
On Wed, 11 Aug 2010 15:37:01 +0100, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2010-08-11 at 15:29 +0100, Gustavo Lopes wrote:
* What about allowing properties with function names as
strings or
array($obj_or_class, 'method'), won't that be needed for
being
On Wed, 11 Aug 2010 15:37:01 +0100, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2010-08-11 at 15:29 +0100, Gustavo Lopes wrote:
* What about allowing properties with function names as
strings or
array($obj_or_class, 'method'), won't that be needed for
being
Hi
Even though one cannot bind a static closure to an instance, one can
rebind its scope with the Closure::bind/Closure::bindTo:
class foo {
static protected $field = foo_field;
static function getClosure() {
return static function () {
Am 23.07.10 06:05, schrieb Adam Harvey:
On 23 July 2010 03:05, Harald Lappharald.l...@gmail.com wrote:
i would like to ask what's the state of $this (and 'self') in closures.
there seems to be no news on this topic for several month now. php 5.3.3 was
just released and still nothing has
Am 23.07.10 06:05, schrieb Adam Harvey:
On 23 July 2010 03:05, Harald Lappharald.l...@gmail.com wrote:
i would like to ask what's the state of $this (and 'self') in closures.
there seems to be no news on this topic for several month now. php 5.3.3 was
just released and still nothing has
On 23.07.2010, at 11:35, Harald Lapp wrote:
Am 23.07.10 06:05, schrieb Adam Harvey:
On 23 July 2010 03:05, Harald Lappharald.l...@gmail.com wrote:
i would like to ask what's the state of $this (and 'self') in closures.
there seems to be no news on this topic for several month now. php 5.3.3
hello,
i would like to ask what's the state of $this (and 'self') in closures.
there seems to be no news on this topic for several month now. php 5.3.3
was just released and still nothing has changed regarding this. so i
would like to ask, for which php release a solution is planned.
thanks
On 23 July 2010 03:05, Harald Lapp harald.l...@gmail.com wrote:
i would like to ask what's the state of $this (and 'self') in closures.
there seems to be no news on this topic for several month now. php 5.3.3 was
just released and still nothing has changed regarding this. so i would like
to
Hi,
Also $this have been wildly discuss here, but the same discussion can be
apply to static/self.
self might be simple to figure out how to bind within a closure.
It can be bind to the name of the class where the closure is define.
static is a more tricky one but it should be the same thing
Hi!
Also $this have been wildly discuss here, but the same discussion can be
apply to static/self.
self might be simple to figure out how to bind within a closure.
It can be bind to the name of the class where the closure is define.
I would guess self binds to the scope, and static binds to
Hi,
My suggestion is to wait until the 15th of January (that's one month
since I started this thread) and that should have been enough time of
everybody.
So, it's 18th - are we moving forward with this?
Yes, Sorry, I've been extremely busy for the last two months, I'll get
back to this in
Hi!
My suggestion is to wait until the 15th of January (that's one month
since I started this thread) and that should have been enough time of
everybody.
So, it's 18th - are we moving forward with this?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
Hello again,
A quick summary of the votes so far (since 15th December):
internals@ votes:
0: (1) Alexey Zakhlestin
A: (1) Hannes Magnusson
C: (0) -
D: (0) -
A+: (2) Christian Seiler, Joey Smith
AS: (1) Stanislav Malyshev
---
5 votes
[AS is Stas' version with
I vote for (A). bind() and bindTo() seem messy to me. However, I
mostly vote for no implicit $this changes in closures (no
javascript-like behaviour), so (A+) approach would be much better than
(C) or (D). (0) case is not my choice, because I really would like to
see $this support in closures
2009/12/15 Christian Seiler chris...@gmx.net:
Hello again,
Discuss away!
I'm a little disappointed by the non-outcome of this debate. Very few
people have responded and most of them seem to agree proposal (A) should
be implemented, perhaps with the additional bind/bindTo as in my
proposal
Richard Quadling wrote:
How much of a use case is binding $this to closures (personally, I
think this is quite a common usage, but I've been using JavaScript so
maybe I've got the wrong head on).
But, if there are significant technical/internal issues with regard to
binding $this to closures,
On Tue, Dec 15, 2009 at 08:46:44PM +0100, Christian Seiler wrote:
(A+): (A) + Closure::bind Closure-bindTo for rebinding
if this is wanted the possibility to call a closure as an object
method. (See last section of RFC for details)
+1 for A+ with class scope option 2
I'm a bit
Hello again,
Discuss away!
I'm a little disappointed by the non-outcome of this debate. Very few
people have responded and most of them seem to agree proposal (A) should
be implemented, perhaps with the additional bind/bindTo as in my
proposal and perhaps not.
The problem here is: (A) was
On 15.12.2009, at 20:01, Christian Seiler wrote:
Hello again,
Discuss away!
I'm a little disappointed by the non-outcome of this debate. Very few
people have responded and most of them seem to agree proposal (A) should
be implemented, perhaps with the additional bind/bindTo as in my
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there is
more time for this to mature if needed inside svn.
Ok, so then I call for
On Tue, Dec 15, 2009 at 20:46, Christian Seiler chris...@gmx.net wrote:
(A): Original closures implementation:
$this is always the object context at
closure creation. No possibility to do
$someObject-closureProperty(...) and thus
no possibility to extend
Hi!
Ok, so then I call for a vote. Again, here are the options:
A+, no direct method calling (get/call problem would be messy)
one additional thing:
$a = static function () {}
should leave $this not bound (in case for some reason you don't want it
to be bound, e.g. to avoid keeping reference
Hi,
Ok, so then I call for a vote. Again, here are the options:
A+, no direct method calling (get/call problem would be messy)
I don't quite follow: Why A+ if no direct method calling? What would be
the point of allowing bindTo() if $obj-closureProp() doesn't work
anyway? If you don't want
On 15.12.2009, at 22:46, Christian Seiler wrote:
Ok, so then I call for a vote. Again, here are the options:
(0): No $this in closures, keep it that way. (keep PHP 5.3 behavior)
I vote for (0)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
A+, but I'm not an internal dev.
On 12/15/2009 21:46, Christian Seiler wrote:
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there
Hi,
Maybe I don't exactly understand the need for closureProperty(); also,
I haven't read the rfc ;-)
My understanding would be that you can treat it as a callable object, like so:
$a = function($msg) { echo $this-id, : , $msg, [ calls: ,
++$this-calls, ];
}
$a-id = 123;
$a(hello world);
If
2009/12/15 Ionut G. Stan ionut.g.s...@gmail.com:
A+, but I'm not an internal dev.
On 12/15/2009 21:46, Christian Seiler wrote:
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the
Christian Seiler wrote
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there
is
more time for this to mature if needed
On Tuesday 15 December 2009 1:46:44 pm Christian Seiler wrote:
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there is
more
On Thu, Nov 19, 2009 at 4:29 PM, Jelrik van Hal jelri...@jelrikvh.nl wrote:
Victor, I do wholeheartedly agree with you about the mess things will be
when allowing $this to refer to different things in different contexts of
calling the same closure (B, C and D): I think it'll prove very
Victor Bolshov wrote:
Hi.
Personally, I beleive that (A) approach is the best: bind $this to
the object scope at creation and never change it, issue error when
$this is used where not available. It also seems to me like this way
it could be implemented with better performance, am I right?
Hi!
If php-people really would like rebinding $this, I beleive this should
be done via method like Closure-bindTo() - to make the fact of
rebinding clear in the code.
However, there is a problem with rebinding $this - that was not
mentioned yet, I think.
This can be a problem, but since PHP
Hi
so you can with $foo-$bar() or $foo()
You're talking about variable functions/methods. But that is not the
subject of discussion. Variable functions/methods are useful but
introduce mess. This is well-known and this feature exists in PHP for
a long time - so everybody should be condidered as
2009/11/16 Christian Seiler chris...@gmx.net:
Hi,
since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP 5.3 I'd like to restart the debate on
$this in closures and object
Hi!
As for public/protected/private ...
$fn = function() use() bind() access(CLOSURE_PUBLIC |
CLOSURE_PROTECTED | CLOSURE_PRIVATE) {};
I have very hard time imagining somebody that would be comfortable using
such a construct. What happened to keeping it simple? And why every
tiniest
Hello,
On Wed, Nov 18, 2009 at 11:44 AM, Stanislav Malyshev s...@zend.com wrote:
I have very hard time imagining somebody that would be comfortable using
such a construct. What happened to keeping it simple? And why every tiniest
feature of every remotest imaginable use case has to be brought
Hi!
That syntax made my eyes hurt, but I think really the problem is that
people want to dynamically add methods with $this in the closure
pointing the the object it has been attached too. Really I like A. but
We can add method to Closure class to allow that. See Closure::bind and
bindTo in
Christian Seiler a écrit :
Hi,
since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP 5.3 I'd like to restart the debate on
$this in closures and object extension.
Foreword: The
Hello,
On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
mathieu.s...@easyflirt.com wrote:
Christian Seiler a écrit :
Hi,
since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP
Chris Stockton a écrit :
Hello,
On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
mathieu.s...@easyflirt.com wrote:
Christian Seiler a écrit :
Hi,
since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure
Hi.
Personally, I beleive that (A) approach is the best: bind $this to
the object scope at creation and never change it, issue error when
$this is used where not available. It also seems to me like this way
it could be implemented with better performance, am I right?
Dynamically changing $this
Hi,
since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP 5.3 I'd like to restart the debate on
$this in closures and object extension.
Foreword: The discussion should center on
Hi!
The original anonymous functions patch[1] contained support for
__FUNCTION__ as a recursion mechanism in closures, such that I should
be able to do something like this:
$factorial = function($n) {
if ($n == 1)
return 1;
else
return $n *
function Y($F) {
$func = function ($f) { return $f($f); };
return $func(function ($f) use($F) {
return $F(function ($x) use($f) {
$ff = $f($f);
return $ff($x);
});
});
}
That's interesting; I
The original anonymous functions patch[1] contained support for
__FUNCTION__ as a recursion mechanism in closures, such that I should
be able to do something like this:
$factorial = function($n) {
if ($n == 1)
return 1;
else
return $n * call_user_func(__FUNCTION__,
Hi,
as Lukas and Johannes have requested, I have removed $this support from
Closures in PHP 5.3.
Technical details on the changes can be found here:
http://wiki.php.net/rfc/closures/removal-of-this
(I didn't have time to write new tests for everything, I just removed
those tests which didn't
On Sat, 2009-01-03 at 14:12 +0100, Marcin Kurzyna wrote:
as you said it's saving the zend_function member that is tricky. i
thought i'd go with saving function string and recompiling it as you
suggested (i don't want to mess with APC although i find the idea of
opcode serialization much
Hi Marcus,
You would need to provide a c level serialization that stores the $this
pointer (the easy part) and the zend_function member (not easy). The
second part requires storing of all static variables, which again is
pretty easy but it also requires to store the function itself, which in
Hi Marcus,
You would need to provide a c level serialization that stores the $this
pointer (the easy part) and the zend_function member (not easy). The
second part requires storing of all static variables, which again is
pretty easy but it also requires to store the function itself, which in
Hello internals and a happy new year.
I've been meaning to ask this for some time now: why aren't closures
serializable? The only on-list discussion about this that i've found is:
http://marc.info/?l=php-internalsm=119837318407795w=2
Personally i'd find serialization of closures very useful
Hello Marcin,
Friday, January 2, 2009, 8:56:41 PM, you wrote:
Hello internals and a happy new year.
I've been meaning to ask this for some time now: why aren't closures
serializable? The only on-list discussion about this that i've found is:
Hi!
so do we even want the toString() method?
IMHO we should drop toString from Closure.
There is one case which *may* cause problems:
function doSomething ($callback) {
if (!is_callable ($callback)) {
throw new Exception (...);
}
// special treatment
if ($callback ==
On 24.07.2008, at 11:10, Christian Seiler wrote:
Personally, I don't care whether a object-to-string cast is present or
not.
So lets remove it?
I don't think Closure can be meaningfully exported. Can we prohibit
it?
Unfortunately, currently not, see the var_export code.
I think we can
Hi,
I am sending this on behalf of Kalle:
1) Closures on class properties just don't work, the only way to do it
is
to do something like:
$c = $a-b;
$c();
Calling: $a-b(); will result in method A::B() does not exists.
2) Closures can be defined as constants values because of its toString
On 22.07.2008, at 13:04, Lukas Kahwe Smith wrote:
1) Closures on class properties just don't work, the only way to do
it is
to do something like:
$c = $a-b;
$c();
Calling: $a-b(); will result in method A::B() does not exists.
would be nice to get this fixed, but at worst it should be
Hi Lukas,
1) Closures on class properties just don't work, the only way to do it is
to do something like:
$c = $a-b;
$c();
Calling: $a-b(); will result in method A::B() does not exists.
Yes, that's expected behaviour (we had a few comments on this on the
list). Compare this to, for example:
Hi Christian,
Am Dienstag, den 22.07.2008, 14:15 +0200 schrieb Christian Seiler:
Calling: $a-b(); will result in method A::B() does not exists.
Yes, that's expected behaviour (we had a few comments on this on the
list).
Hm, I'm not sure who expected it that way. At least Stas and myself
Hi!
so do we even want the toString() method?
IMHO we should drop toString from Closure.
Maybe it could return some relevant information for exporting the
closure across
data
not a huge biggy to me.
I don't think Closure can be meaningfully exported. Can we prohibit it?
I guess this
Hi Stas,
Am Dienstag, den 22.07.2008, 13:09 -0700 schrieb Stanislav Malyshev:
[...]
I'm all for doing it, the problem is the syntax $foo-bar() is already
used. But you can do $foo-bar-__invoke()!
Can't we change zend_std_get_method() to return a zend_internal_function
struct in case of a
Hello Lars,
actually this is a very good idea and should work :-)
marcus
Tuesday, July 22, 2008, 10:15:03 PM, you wrote:
Hi Stas,
Am Dienstag, den 22.07.2008, 13:09 -0700 schrieb Stanislav Malyshev:
[...]
I'm all for doing it, the problem is the syntax $foo-bar() is already
used. But
Hello Stanislav,
Tuesday, July 22, 2008, 10:08:11 PM, you wrote:
Hi!
so do we even want the toString() method?
IMHO we should drop toString from Closure.
Sam here. It makes no sense anyway. This mail thread just proved that.
Maybe it could return some relevant information for exporting
Hi!
Can't we change zend_std_get_method() to return a zend_internal_function
struct in case of a closure on a property? The only thing that needs to
That means that:
1. We can't have properties named same as functions anymore
2. We'd have to check properties every time method name was not
Hello Stanislav,
Tuesday, July 22, 2008, 11:07:58 PM, you wrote:
Hi!
Can't we change zend_std_get_method() to return a zend_internal_function
struct in case of a closure on a property? The only thing that needs to
That means that:
1. We can't have properties named same as functions
Hi!
Nope. It means if you have a function named foo and a property foo that
sores a closure and then call foo(), then obviously the function is called
rather than the closure.
That means you can't call the closure, and nothing alerts you of the
problem.
2. We'd have to check properties
Hello Stanislav,
Wednesday, July 23, 2008, 12:54:48 AM, you wrote:
Hi!
Nope. It means if you have a function named foo and a property foo that
sores a closure and then call foo(), then obviously the function is called
rather than the closure.
That means you can't call the closure, and
Hi!
H, the amount of problems is pretty long. So even though it might sound
cool to do it. It is the better deceision to not allow it. Also you've
shown several paths where it would slow general execution down. Yet I hate
not being able to easily make it work.
Well, $foo-bar-__invoke() is
Hi all,
Noticed that PHP 6 snapshots aren't working and got these errors when trying
to build:
zend_API.obj : error LNK2019: unresolved external symbol _zend_get_closure
referenced in function _zend_is_callable_ex
zend_execute.obj : error LNK2001: unresolved external symbol
_zend_get_closure
Sorted now, the new file was missing from the build files.
Scott
Matt Wilmas wrote:
Hi all,
Noticed that PHP 6 snapshots aren't working and got these errors when trying
to build:
zend_API.obj : error LNK2019: unresolved external symbol _zend_get_closure
referenced in function
Hi Scott,
Ah thanks, so simple! :-O I should've investigated first since I figured it
was probably a Windows-specific file, and not a missing #include, etc.
- Original Message -
From: Scott MacVicar
Sent: Wednesday, July 09, 2008
Sorted now, the new file was missing from the build
82 matches
Mail list logo
