> On 3 Aug 2014, at 22:50, Andrea Faulds wrote:
>
> Good evening,
>
> I am proposing two new RFCs. As they are both inter-related and
> complementary, with the second having the first as a prerequisite, I’m making
> just a single email to cover both:
>
> https://wiki.php.net/rfc/closure_appl
On Aug 10, 2014, at 11:20 AM, Andrea Faulds wrote:
> Hi!
>
> Sorry for the slow response, I’ve been on holiday.
No problem!
> On 8 Aug 2014, at 01:32, Josh Watzman wrote:
>
>> The RFC goes a long way to fixing this, but one important place it misses is
>> with function references to private
it's ambiguous with regular object creation.
Thanks. Dmitry.
On Tue, Aug 12, 2014 at 12:47 AM, Michael Wallner wrote:
> How about 'new Function()'?
>
> Might be a WTF that it creates an instance of Closure, though.
> On 11 Aug 2014 22:32, "Dmitry Stogov" wrote:
>
>> We didn't keep pointers t
How about 'new Function()'?
Might be a WTF that it creates an instance of Closure, though.
On 11 Aug 2014 22:32, "Dmitry Stogov" wrote:
> We didn't keep pointers to functions in opcodes (however it possible in
> some cases).
> Instead we use cache_slots in op_array->run_time_cache array to keep
We didn't keep pointers to functions in opcodes (however it possible in
some cases).
Instead we use cache_slots in op_array->run_time_cache array to keep
pointers to classes and functions.
Anyway, it must be quite easy to extend the patch.
Thanks. Dmitry.
On Mon, Aug 11, 2014 at 11:33 PM, Andre
On 11 Aug 2014, at 20:07, Dmitry Stogov wrote:
>
> may be:
>
> $a = function strlen;
>
> or
>
> $a = function(stren);
>
> but these are not excellent as well :(
I wanted to do the first, but it caused a shift/reduce conflict in the parser
due to ambiguity with function () {}. The latter h
On Mon, Aug 11, 2014 at 10:09 PM, Andrea Faulds wrote:
>
> On 11 Aug 2014, at 08:36, Dmitry Stogov wrote:
>
> > Hi Andrea,
> >
> > Could you measure the performance impact of function referencing.
> >
> > > $func = "strlen";
> > for ($i = 0; $i < 1; $i++) {
> > $func("hello");
> > }
> >
On 11 Aug 2014, at 08:36, Dmitry Stogov wrote:
> Hi Andrea,
>
> Could you measure the performance impact of function referencing.
>
> $func = "strlen";
> for ($i = 0; $i < 1; $i++) {
> $func("hello");
> }
> ?>
>
> vs
>
> $func = &strlen;
> for ($i = 0; $i < 1; $i++) {
> $fu
On 11 Aug 2014, at 12:08, Rowan Collins wrote:
> I understand that &$foo->method won't work, but that's what I mean by
> pre-supposing the proposed syntax.
>
> If you had a different syntax, such as £function (I know it's not a sensible
> choice, but it's an example of something with no confl
Andrea Faulds wrote (on 10/08/2014):
On 10 Aug 2014, at 22:00, Rowan Collins wrote:
You're rather pre-supposing the proposed syntax there, and letting it lead the
semantics rather than vice versa. The point is it would be useful to allow
creation of a pre-bound closure based on an existing m
Hi Andrea,
Could you measure the performance impact of function referencing.
vs
I don't like the "&" syntax a lot, but I understand that it's a compromise
between readability and implementation complication.
The patch probably misses support for "&self::foo", "&parent::foo",
"&static::foo".
On 10 Aug 2014, at 22:00, Rowan Collins wrote:
> You're rather pre-supposing the proposed syntax there, and letting it lead
> the semantics rather than vice versa. The point is it would be useful to
> allow creation of a pre-bound closure based on an existing method, so it
> would be good if
On 10 August 2014 19:20:09 GMT+01:00, Andrea Faulds wrote:
>Hi!
>
>Sorry for the slow response, I’ve been on holiday.
>
>On 8 Aug 2014, at 01:32, Josh Watzman wrote:
>
>> The RFC goes a long way to fixing this, but one important place it
>misses is with function references to private and protecte
Hi!
Sorry for the slow response, I’ve been on holiday.
On 8 Aug 2014, at 01:32, Josh Watzman wrote:
> The RFC goes a long way to fixing this, but one important place it misses is
> with function references to private and protected methods. The crux of the
> issue is that allowing an unbound c
[Andrea, please forward this to internals if you don't see my message appear
there in a few hours; as you know, FB is working through issues sending email
to internals, and though I think I know how to get it through, if it doesn't
make it, please help :) Thanks!]
On Aug 4, 2014, at 12:49 PM, A
On 6 Aug 2014, at 16:01, Ralph Schindler wrote:
> When you put it like this, that further enhances my argument for adding
> a call() and/or a bindCall(). Having to rely on __invoke() means
> you're coding around and relying on an implementation detail, as opposed
> to the class's published API.
Hi!
On 5 August 2014 18:01, Ralph Schindler
wrote: At the risk of stating the obvious, can’t you just use
$f->bar->__invoke()?
Actually, it was not immediately obvious that __invoke() was a
method from the docs as it is a side-note and not in the class
signature breakout. Oops! ;)
http://p
Closure apply
On Aug 5, 2014 8:13 PM, "Andrea Faulds" wrote:
>
> On 5 Aug 2014, at 18:51, Pierre Joye wrote:
>
> > For your RFC, given other solutions, i fail to find one
>
> To which RFC do you refer?
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
On 5 Aug 2014, at 18:51, Pierre Joye wrote:
> For your RFC, given other solutions, i fail to find one
To which RFC do you refer?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Aug 5, 2014 7:41 PM, "Andrea Faulds" wrote:
>
>
> On 5 Aug 2014, at 18:40, Pierre Joye wrote:
>
> > On Aug 5, 2014 6:40 PM, "Andrea Faulds" wrote:
> > > Side note, but that’s because __invoke on Closure doesn’t actually
exist. It’s a method that is created by trying to access it and ceases to
On 5 Aug 2014, at 18:40, Pierre Joye wrote:
> On Aug 5, 2014 6:40 PM, "Andrea Faulds" wrote:
> > Side note, but that’s because __invoke on Closure doesn’t actually exist.
> > It’s a method that is created by trying to access it and ceases to exist
> > once called. Freaky, right?
>
> Do you h
Hi Andrea,
On Aug 5, 2014 6:40 PM, "Andrea Faulds" wrote:
>
>
> On 5 Aug 2014, at 17:08, Marco Pivetta wrote:
>
> >
> > On 5 August 2014 18:01, Ralph Schindler
wrote:
> > At the risk of stating the obvious, can’t you just use
$f->bar->__invoke()?
> >
> > >Actually, it was not immediately obviou
On 5 Aug 2014, at 17:08, Marco Pivetta wrote:
>
> On 5 August 2014 18:01, Ralph Schindler wrote:
> At the risk of stating the obvious, can’t you just use $f->bar->__invoke()?
>
> >Actually, it was not immediately obvious that __invoke() was a method from
> >the docs as it is a side-note and
On 5 August 2014 18:01, Ralph Schindler wrote:
> At the risk of stating the obvious, can’t you just use $f->bar->__invoke()?
>>
>
> Actually, it was not immediately obvious that __invoke() was a method from
> the docs as it is a side-note and not in the class signature breakout.
> Oops! ;)
>
> ht
At the risk of stating the obvious, can’t you just use $f->bar->__invoke()?
Actually, it was not immediately obvious that __invoke() was a method
from the docs as it is a side-note and not in the class signature
breakout. Oops! ;)
http://php.net/manual/en/class.closure.php
That said, call()
On 5 August 2014 17:50, Andrea Faulds wrote:
>
> On 5 Aug 2014, at 16:20, Ralph Schindler wrote:
>
> > "->call()" would facilitate the following syntax, which I'd argue has
> greater semantic meaning than the call_user_func() variant:
> >
> > $f->bar->call()->call();
>
> At the risk of stating
On 5 Aug 2014, at 16:20, Ralph Schindler wrote:
> "->call()" would facilitate the following syntax, which I'd argue has greater
> semantic meaning than the call_user_func() variant:
>
> $f->bar->call()->call();
At the risk of stating the obvious, can’t you just use $f->bar->__invoke()?
--
An
Andrea + Marco
Is the advantage of `Closure#call()` only performance? Because I don't see
other advantages otherwise, and I don't think the performance impact is
relevant.
I like the proposal, but with some modifications. I am unsure if there
is another RFC out there on function de-referenci
Hi!
> Right, while &FooBar::$methodname would conflict, &$classname::foo
> would not. I do neither for the sake of consistency, as having one
> but not the other worse might cause confusion. This has the benefit,
> I suppose, that & is completely static. You can see at “compile-time”
> whether it’
On 4 Aug 2014, at 20:41, Rowan Collins wrote:
> > It does not permit dynamic references such as |&$classname::foo|, due to
> > conflicts with existing syntax and for symmetry (while |&$classname::foo|
> > would be doable, |&FooBar::$foo| is not, so we do neither).
>
> I'm not entirely sure of
Andrea Faulds wrote (on 04/08/2014):
It doesn’t collide, there is no syntactical ambiguity at an engine level, at
least.
You do mention one collision in the RFC though:
> It does not permit dynamic references such as |&$classname::foo|, due
to conflicts with existing syntax and for symmetry
Andrea Faulds wrote (on 04/08/2014):
On 4 Aug 2014, at 01:53, Thomas Bley wrote:
from userland perspective, I would prefer to open the Closure constructor
instead of adding new syntax:
$qux = new FooBar(3);
// $func = &FooBar::getStatic;
$func = new Closure(array('FooBar', 'getStatic'));
$fu
Hi!
> It doesn’t look exactly the same, you can’t reference a constant.
That's why it is bad - because it looks like you're referencing a
constant, but in fact it does something completely unrelated.
> In C and C++ you get a function pointer. Here you get a closure. In
> both cases you get somet
On 4 Aug 2014, at 19:33, Stas Malyshev wrote:
>> It doesn’t collide, there is no syntactical ambiguity at an engine
>> level, at least. It does unfortunately look similar, however. The
>
> That's the collision. It looks exactly the same, but does entirely
> different thing. This is not good.
I
Hi!
> It doesn’t collide, there is no syntactical ambiguity at an engine
> level, at least. It does unfortunately look similar, however. The
That's the collision. It looks exactly the same, but does entirely
different thing. This is not good.
> choice of syntax is largely for a lack of better al
On 4 August 2014 15:02, Andrea Faulds wrote:
>
> On 4 Aug 2014, at 13:27, Marco Pivetta wrote:
>
> > The fact that I'm arguing about is "yet another method to maintain" for
> an API that can simply live in userland (and is easier to
> maintain/upgrade/etc)...
> > Unless there's a huge overhead,
On 4 Aug 2014, at 13:27, Marco Pivetta wrote:
> The fact that I'm arguing about is "yet another method to maintain" for an
> API that can simply live in userland (and is easier to
> maintain/upgrade/etc)...
> Unless there's a huge overhead, I don't see a problem with creating new
> closures:
On 4 August 2014 14:11, Andrea Faulds wrote:
> On 4 Aug 2014, at 12:36, Marco Pivetta wrote:
>
> > Is the advantage of `Closure#call()` only performance? Because I don't
> see other advantages otherwise, and I don't think the performance impact is
> relevant.
>
> There is a performance advantage
Good morning!
On 4 Aug 2014, at 06:48, Nikita Nefedov wrote:
> Hey Andrea,
>
> I really love function referencing RFC, this is something I miss in PHP and
> would I have a voting right I'd would +1 even in this state of it.
> But I dislike a bit the fact that we start to use Closure for everyt
On 3 August 2014 23:50, Andrea Faulds wrote:
> Good evening,
>
> I am proposing two new RFCs. As they are both inter-related and
> complementary, with the second having the first as a prerequisite, I’m
> making just a single email to cover both:
>
> https://wiki.php.net/rfc/closure_apply
> https:
Hi!
> https://wiki.php.net/rfc/function_referencing
This syntax collides with by-ref assignment and by-ref arrays, which is
not good. Different things should not look the same.
I'm not sure also how exactly non-closures can function as closures - if
you take SplFixedArray::getSize and rebind it
Hey Andrea,
I really love function referencing RFC, this is something I miss in PHP
and would I have a voting right I'd would +1 even in this state of it.
But I dislike a bit the fact that we start to use Closure for everything,
I really wish we had a dedicated type for functions (read functi
On 4 Aug 2014, at 01:53, Thomas Bley wrote:
> from userland perspective, I would prefer to open the Closure constructor
> instead of adding new syntax:
>
> $qux = new FooBar(3);
> // $func = &FooBar::getStatic;
> $func = new Closure(array('FooBar', 'getStatic'));
> $func($qux); // 3
You can a
Hello Andrea,
from userland perspective, I would prefer to open the Closure constructor
instead of adding new syntax:
$qux = new FooBar(3);
// $func = &FooBar::getStatic;
$func = new Closure(array('FooBar', 'getStatic'));
$func($qux); // 3
Regards
Thomas
Andrea Faulds wrote on 03.08.2014 23:5
Good evening,
I am proposing two new RFCs. As they are both inter-related and complementary,
with the second having the first as a prerequisite, I’m making just a single
email to cover both:
https://wiki.php.net/rfc/closure_apply
https://wiki.php.net/rfc/function_referencing
Both have written,
45 matches
Mail list logo
