Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

Hi 2015-09-29 7:30 GMT+02:00 Pierre Joye : > This model totally failed for us in the past. And given that these keywords > will be used for anything related to async APIs, let reserve them and put > our users on the safe side already. While I understand the concern, I

Re: [PHP-DEV] Arrow function expressions in PHP

On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison wrote: > > I do not think it is feasible to make the parser do backtracking or > anything of that sort. How do others feel? > >> PS: the [fn($x) => $x * 2] seems ambigous, from reader's POV; key of >> the item is result of fn($x) and

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Tue, 2015-09-29 at 08:49 +0200, Kalle Sommer Nielsen wrote: > Hi > > 2015-09-29 7:30 GMT+02:00 Pierre Joye : > > This model totally failed for us in the past. And given that these keywords > > will be used for anything related to async APIs, let reserve them and put > >

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

We shouldn't reserve words on a whim ... async/await doesn't solve any problems for multithreaded programming, at all ... it solves problems for asynchronous programming, a different concept ... let's not confuse the two ... As mentioned you don't need any special syntax or reserved words for

[PHP-DEV] Benchmark Results for PHP Master 2015-09-29

Results for project php-src-nightly, build date 2015-09-29 05:12:58+03:00 commit: 2cacf5770daa13b0c498f48d1f7b20b6585a70bf revision_date: 2015-09-28 17:01:16-07:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] [RFC] [DRAFT]: Consistent callables

Hello internals, Here is a draft RFC to make the callable type in PHP be consistent and have much fewer surprises. https://wiki.php.net/rfc/consistent_callables This RFC is probably not ready for the formal discussion that is held before a vote on it can be held as there may be some more

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

Sorry, that was all over the place ... was on way out the door ... What I should have said is that async/await don't directly solve problems, they are nice calling conventions for async APIs, but the APIs must exist before we talk about reserving or adding anything else. The real problem is that

Fwd: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

Hi Dan, I'm not sure if i follow, -> why not just do "return function() { $this->myPrivateMethod(); };" If you really really need a closure to be returned that calls a private method? because this should return a closure thats bound to the actual object? -> this should be easy enough to do

[PHP-DEV] Injecting structure to ZEND_NEW

I'm trying to pass a new structure into the ZEND_NEW handler which will be used to change the behaviour of zend_fetch_class_by_name. The issue I'm having though is the operands won't support the new type unless I compile it to zval, but I can't use zend_execute_data to reference that in a

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

On Tue, Sep 29, 2015 at 8:23 AM, Dan Ackroyd wrote: > Hello internals, > > I'd like to start a discussion of a proposal to allow closures to be > created in user-land without having to use a whole lot of reflection > code. > > https://wiki.php.net/rfc/closurefromcallable

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On 9/29/2015 6:52 AM, Joe Watkins wrote: We shouldn't reserve words on a whim ... async/await doesn't solve any problems for multithreaded programming, at all ... it solves problems for asynchronous programming, a different concept ... let's not confuse the two ... Actually, it does.

[PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

Hello internals, I'd like to start a discussion of a proposal to allow closures to be created in user-land without having to use a whole lot of reflection code. https://wiki.php.net/rfc/closurefromcallable Thanks to Joe and Bob for the assistance in the patch. cheers Dan Ack -- PHP Internals

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

On 29/09/15 16:23, Dan Ackroyd wrote: > Hello internals, > > I'd like to start a discussion of a proposal to allow closures to be > created in user-land without having to use a whole lot of reflection > code. > > https://wiki.php.net/rfc/closurefromcallable > > Thanks to Joe and Bob for the

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

+1 on the concept, I tried to argue it belongs in /Zend too ... still think it does ... On Tue, Sep 29, 2015 at 3:50 PM, Michael Wallner wrote: > On 29/09/15 16:23, Dan Ackroyd wrote: > > Hello internals, > > > > I'd like to start a discussion of a proposal to allow closures to be

Re: [PHP-DEV] Injecting structure to ZEND_NEW

I think you are looking for opcode handlers, what you want to do is implement a ZEND_NEW handler ... For reference, xdebug and uopz overload handlers, as well as many other extensions ... Cheers Joe On Tue, Sep 29, 2015 at 3:47 PM, Dominic Grostate < codekest...@googlemail.com> wrote: > I'm

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

> On Tue, Sep 29, 2015 at 3:50 PM, Michael Wallner wrote: >> +1, I'm not sure it belongs into ext/reflection, though? On 29 September 2015 at 14:54, Joe Watkins wrote: > +1 on the concept, I tried to argue it belongs in /Zend too ... still think Sure I'll

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

On 29 September 2015 at 14:56, Peter Petermann wrote: > why not just do "return function() { $this->myPrivateMethod(); };" That would not work if there were any parameters to the function. Also all other information would need to be duplicated e.g. the return type. >

Re: [PHP-DEV] Injecting structure to ZEND_NEW

https://github.com/orolyn/php-src/blob/generics/Zend/zend_vm_def.h See opcode ZEND_TYPE_ARGUMENT. I haven't built the type_argument_list yet, but once I have I will need to pass it to the next op handler NEW. Where it will be passed to the modified second parameter of

Re: [PHP-DEV] Injecting structure to ZEND_NEW

lxr: zend_set_user_opcode_handler On Tue, Sep 29, 2015 at 4:57 PM, Joe Watkins wrote: > I think you are looking for opcode handlers, what you want to do is > implement a ZEND_NEW handler ... > > For reference, xdebug and uopz overload handlers, as well as many other >

Re: [PHP-DEV] Injecting structure to ZEND_NEW

Sorry, I'm not able to make sense of what you are doing ... got a patch ? Cheers Joe On Tue, Sep 29, 2015 at 5:29 PM, Dominic Grostate < codekest...@googlemail.com> wrote: > Hi, ive already started working with the handlers. I've set up the > parser to accept addition syntax before the ctor.

Re: [PHP-DEV] Injecting structure to ZEND_NEW

Hi, ive already started working with the handlers. I've set up the parser to accept addition syntax before the ctor. The type arguments are passed to a new opcode handler which triggers prior to NEW but after FETCH_CLASS (if dynamic, after resolve on CONST). This needs to override the fetching

[PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

> On Sep 28, 2015, at 3:29 AM, S.A.N wrote:> > Are > there any future plans for - async/await?> This need to know now, not to use > these words to constants, and class names...> > -- > PHP Internals - PHP > Runtime Development Mailing List> To unsubscribe, visit: >

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

Hi Thomas, > On Sep 29, 2015, at 10:22 AM, Thomas Hruska wrote: > > On 9/29/2015 6:52 AM, Joe Watkins wrote: >> We shouldn't reserve words on a whim ... >> >> async/await doesn't solve any problems for multithreaded programming, at >> all ... it solves problems for

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

Thomas, On Tue, Sep 29, 2015 at 11:22 AM, Thomas Hruska wrote: > On 9/29/2015 6:52 AM, Joe Watkins wrote: >> >> We shouldn't reserve words on a whim ... >> >> async/await doesn't solve any problems for multithreaded programming, at >> all ... it solves problems for

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Wed, Sep 30, 2015 at 1:16 AM, Sara Golemon wrote: > On Tue, Sep 29, 2015 at 3:00 PM, Dmitry Stogov wrote: > > I think, we don't need to reserve words, until we decide to implement > this. > > The context sensitive scanner introduced in 7.0 makes the problem

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

On Tue, Sep 29, 2015 at 8:23 AM, Dan Ackroyd wrote: > Hello internals, > > I'd like to start a discussion of a proposal to allow closures to be > created in user-land without having to use a whole lot of reflection > code. > > https://wiki.php.net/rfc/closurefromcallable >

Re: [PHP-DEV] Arrow function expressions in PHP

On Tue, Sep 29, 2015 at 12:23 AM, Pavel Kouřil wrote: > On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison wrote: >> >> I do not think it is feasible to make the parser do backtracking or >> anything of that sort. How do others feel? >> >>> PS: the [fn($x) => $x *

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Wed, Sep 30, 2015 at 1:22 AM, Johannes Schlüter wrote: > On Tue, 2015-09-29 at 11:29 -0700, Sara Golemon wrote: > > On Mon, Sep 28, 2015 at 10:30 PM, Pierre Joye > wrote: > > > This model totally failed for us in the past. And given that these >

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

I think, we don't need to reserve words, until we decide to implement this. The context sensitive scanner introduced in 7.0 makes the problem less serious. $ sapi/cli/php -r 'class foo { static function use() {echo "ok\n";}} foo::use();' ok Sara, related question... Is the semantic of

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Tue, Sep 29, 2015 at 3:00 PM, Dmitry Stogov wrote: > I think, we don't need to reserve words, until we decide to implement this. > The context sensitive scanner introduced in 7.0 makes the problem less > serious. > > $ sapi/cli/php -r 'class foo { static function use() {echo

[PHP-DEV] Re: [PHP-CVS] com php-src: Allow an experimental VM with tail call dispatch technique (disabled by default). This VM may work only if all tail calls are optimized, otherwaise it will crach b

Hi Dmitry, Just curious about this. :-) For dispatching next opcode, isn't a tail call an indirect jmp instruction, just like a computed goto? So how is it different than GOTO executor...? Debugging/compatibility? (Unless it can work with MSVC -- oh nevermind, looks like it's only with

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Tue, 2015-09-29 at 11:29 -0700, Sara Golemon wrote: > On Mon, Sep 28, 2015 at 10:30 PM, Pierre Joye wrote: > > This model totally failed for us in the past. And given that these keywords > > will be used for anything related to async APIs, let reserve them and put > > our

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Tue, 2015-09-29 at 21:04 +0300, S.A.N wrote: > > When Node.js appear async/await, many developers and projects will > migrate to a Node.js, if PHP is not implement async APIs. > > Hopefully, Dmitry Stogov and others, will make another surprise: > PHP-Next-Async? :) My claim is that if you're

[PHP-DEV] Re: [PHP-CVS] com php-src: Allow an experimental VM with tail call dispatch technique (disabled by default). This VM may work only if all tail calls are optimized, otherwaise it will crach b

On Wed, Sep 30, 2015 at 1:16 AM, Matt Wilmas wrote: > Hi Dmitry, > > Just curious about this. :-) For dispatching next opcode, isn't a tail > call an indirect jmp instruction, just like a computed goto? So how is it > different than GOTO executor...?

Re: [PHP-DEV] taint

Hey: On Thu, Sep 17, 2015 at 2:37 AM, Stanislav Malyshev wrote: > Hi! > >>> Taint is blacklisting. >>> >> Last time I checked marking all user input as tainted and requiring >> "untainting" before usage in sensitive functions is whitelisting and not >> blacklisting. > > I

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

> Implementing elegant, readable, and stable asynchronous code in userland PHP > code is very possible. In fact, I’ve done exactly this with Icicle > (https://github.com/icicleio/icicle). Icicle uses generators and promises to > implement coroutines. When a coroutine yields a promise, the

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On 29 September 2015 16:22:30 BST, Thomas Hruska wrote: >On 9/29/2015 6:52 AM, Joe Watkins wrote: >> We shouldn't reserve words on a whim ... >> >> async/await doesn't solve any problems for multithreaded programming, >at >> all ... it solves problems for asynchronous

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Mon, Sep 28, 2015 at 10:30 PM, Pierre Joye wrote: > This model totally failed for us in the past. And given that these keywords > will be used for anything related to async APIs, let reserve them and put > our users on the safe side already. > Like that time we reserved