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
We can disable immutable arrays when opcache not loaded or disabled.
But it's going to be difficult to disable them when script can't fit into
SHM, because at the moment of compilation (or optimization) we don't know
the final required size.
Thanks. Dmitry.
On Mon, Aug 4, 2014 at 9:26 PM, Andrea
On 4 Aug 2014, at 18:06, Pierre Joye wrote:
> As I agree that a solution has to be found, introducing pragma is
> definitively not something I like to see in PHP, options like that are
> way too low level and should not be exposed in userland. It will make
> PHP way too complex.
Perhaps I’m bei
hi Dmitry,
On Mon, Aug 4, 2014 at 6:23 PM, Dmitry Stogov wrote:
> hi Pascal,
>
> Laruence is right - immutable arrays are not destroyed until the end of
> request and this causes a problem in your case.
>
> I've committed a partial fix that destroys unnecessary copies when script
> is cached by O
hi Pascal,
Laruence is right - immutable arrays are not destroyed until the end of
request and this causes a problem in your case.
I've committed a partial fix that destroys unnecessary copies when script
is cached by OPCache, but it doesn't work without opcache or when it
doesn't have enough sha
Hey guys,
Are there any news about when PHP is going to be fully x64 for Windows?
I have a software repository site that I would like to have fully using
PHP to upload ISO images, right now, I'm trying to use PHP 5.5.15 x64
and 5.6 RC3, but so far what I can get uploaded using PHP is 1.92 GB.
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:
Bob,
I see you already committed this into PHP-5.6.
I would agree that new behavior is more consistent and may be committed
into master, but I'm still afraid that it may bring as problems because of
last minute changes and lack of tests coverage.
Thanks. Dmitry.
On Sun, Jul 27, 2014 at 3:02 PM
18 matches
Mail list logo
