Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On 18/08/2014 18:41, Nikita Popov wrote: I've opened the vote on the Abstract Syntax Tree RFC: https://wiki.php.net/rfc/abstract_syntax_tree#vote After speaking with other members of AFUP (French UG) about this RFC, we pretty much all agree that a cleaner compilation process is a nice improvement. It should help us getting some syntax options that were impossible before, and there is not too much impact for developers and their existing applications. So, basically: +1 -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 3:41 PM, Levi Morrison wrote: > On Wed, Aug 20, 2014 at 7:30 AM, Paul Dragoonis > wrote: > > On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans wrote: > > > >> Hi Nikita, > >> > >> I reviewed the AST RFC on my way to vote but there was something that > >> wasn’t clear to me. > >> This patch introduces some semantic/behavioral changes in addition to > the > >> AST. > >> Are these as a side-effect of how AST was implemented? Or are they > >> unrelated to the AST patch? > >> I think some of them make sense but I’m having a bit of a hard time > >> separating out the benefits of the AST (which I really like) and making > >> other changes to semantics w/o really understanding if they are > >> side-effects and we have no choice vs. we’re trying to solve for two > >> separate items in one RFC. > >> Any BC breaks here we think could bite us? > >> > > > > Hi Nikita, > > > > I second some of Andi's concerns about behavioural changes, some things > > working from right-to-left and not left-to-right. Are these things that > we > > can adapt the AST part or tweak another part to make this more consistent > > with previous versions of PHP. > > I just had a chat with Paul about this, and there was a > misunderstanding about what this RFC actually does regarding > left-to-right evaluation on list() constructs. I also saw this > misunderstanding in a few other places, so it seems to be a common > misunderstanding. > > Under the proposed changes as well as in PHP 5.x, the end result of > the following is the same: > > list($a, $b) = array(1, 2); > > $a will be 1 and $b will be 2. Again, this hasn't changed. The > difference is that in PHP 5.x the variable $b will be assigned 2 > before $a is assigned 1; under these changes $a will be assigned 1 > first and then $b will be assigned 2. > I'm happy with this behaviour and agree that the AST version is what I would expect, my confusion was that I thought PHP 5.x was 1,2 and the AST was 2,1 which it of course is not the case. Now you could see why I raised concerns about this in the first place. > > This really only affects strange situations, such as ones listed in the > RFC. >
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 7:30 AM, Paul Dragoonis wrote: > On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans wrote: > >> Hi Nikita, >> >> I reviewed the AST RFC on my way to vote but there was something that >> wasn’t clear to me. >> This patch introduces some semantic/behavioral changes in addition to the >> AST. >> Are these as a side-effect of how AST was implemented? Or are they >> unrelated to the AST patch? >> I think some of them make sense but I’m having a bit of a hard time >> separating out the benefits of the AST (which I really like) and making >> other changes to semantics w/o really understanding if they are >> side-effects and we have no choice vs. we’re trying to solve for two >> separate items in one RFC. >> Any BC breaks here we think could bite us? >> > > Hi Nikita, > > I second some of Andi's concerns about behavioural changes, some things > working from right-to-left and not left-to-right. Are these things that we > can adapt the AST part or tweak another part to make this more consistent > with previous versions of PHP. I just had a chat with Paul about this, and there was a misunderstanding about what this RFC actually does regarding left-to-right evaluation on list() constructs. I also saw this misunderstanding in a few other places, so it seems to be a common misunderstanding. Under the proposed changes as well as in PHP 5.x, the end result of the following is the same: list($a, $b) = array(1, 2); $a will be 1 and $b will be 2. Again, this hasn't changed. The difference is that in PHP 5.x the variable $b will be assigned 2 before $a is assigned 1; under these changes $a will be assigned 1 first and then $b will be assigned 2. This really only affects strange situations, such as ones listed in the RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 2:57 PM, Nikita Popov wrote: > On Wed, Aug 20, 2014 at 3:30 PM, Paul Dragoonis > wrote: > >> Hi Nikita, >> >> I second some of Andi's concerns about behavioural changes, some things >> working from right-to-left and not left-to-right. Are these things that we >> can adapt the AST part or tweak another part to make this more consistent >> with previous versions of PHP. Improving consistency when changing >> underlying parts is a good migration technique. Facebook done this when >> they implemented HHMV, they didn't fix bugs but made a like-for-like stable >> copy before tackling improvements. >> >> Do you feel it's an important goal to keep consistency from PHP 5.x to >> PHP 7, with regards to the behaviour of syntax parsing/behaviour, or do you >> feel that you can live with these non-BC changes? >> >> Many thanks, >> Paul >> > > Is there some *particular* change that concerns you? This is something > that needs to be decided on a case-by-case basis. The RFC contains a list > of changes. All of them are minor adjustments verging on bug fixes, which > imho are all within the bounds of reasonable changes for a major version. > However if you can provide argument why one of the listed changes is > incorrect (as in, introduces less intuitive/consistent/... behavior) or has > larger BC impact than anticipated, then I'm open to discussion that. > I will get back to you with some specific use cases that I see could be potentially problematic and non-intuitive. > > > Nikita >
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 3:30 PM, Paul Dragoonis wrote: > Hi Nikita, > > I second some of Andi's concerns about behavioural changes, some things > working from right-to-left and not left-to-right. Are these things that we > can adapt the AST part or tweak another part to make this more consistent > with previous versions of PHP. Improving consistency when changing > underlying parts is a good migration technique. Facebook done this when > they implemented HHMV, they didn't fix bugs but made a like-for-like stable > copy before tackling improvements. > > Do you feel it's an important goal to keep consistency from PHP 5.x to PHP > 7, with regards to the behaviour of syntax parsing/behaviour, or do you > feel that you can live with these non-BC changes? > > Many thanks, > Paul > Is there some *particular* change that concerns you? This is something that needs to be decided on a case-by-case basis. The RFC contains a list of changes. All of them are minor adjustments verging on bug fixes, which imho are all within the bounds of reasonable changes for a major version. However if you can provide argument why one of the listed changes is incorrect (as in, introduces less intuitive/consistent/... behavior) or has larger BC impact than anticipated, then I'm open to discussion that. Nikita
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans wrote: > Hi Nikita, > > I reviewed the AST RFC on my way to vote but there was something that > wasn’t clear to me. > This patch introduces some semantic/behavioral changes in addition to the > AST. > Are these as a side-effect of how AST was implemented? Or are they > unrelated to the AST patch? > I think some of them make sense but I’m having a bit of a hard time > separating out the benefits of the AST (which I really like) and making > other changes to semantics w/o really understanding if they are > side-effects and we have no choice vs. we’re trying to solve for two > separate items in one RFC. > Any BC breaks here we think could bite us? > Hi Nikita, I second some of Andi's concerns about behavioural changes, some things working from right-to-left and not left-to-right. Are these things that we can adapt the AST part or tweak another part to make this more consistent with previous versions of PHP. Improving consistency when changing underlying parts is a good migration technique. Facebook done this when they implemented HHMV, they didn't fix bugs but made a like-for-like stable copy before tackling improvements. Do you feel it's an important goal to keep consistency from PHP 5.x to PHP 7, with regards to the behaviour of syntax parsing/behaviour, or do you feel that you can live with these non-BC changes? Many thanks, Paul > > Any insight would be much appreciated. > Thanks! > Andi > > On Aug 18, 2014, at 9:41 AM, Nikita Popov wrote: > > > Hi internals! > > > > I've opened the vote on the Abstract Syntax Tree RFC: > > > >https://wiki.php.net/rfc/abstract_syntax_tree#vote > > > > Thanks, > > Nikita > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
got it. thanks! On Aug 18, 2014, at 11:36 PM, Dmitry Stogov wrote: > Hi Andi, > > We already discussed most of semantic changes introduced in AST patch. > Most of them came from another approved RFC > https://wiki.php.net/rfc/uniform_variable_syntax > > Thanks. Dmitry. > > > On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote: > Hi Nikita, > > I reviewed the AST RFC on my way to vote but there was something that wasn’t > clear to me. > This patch introduces some semantic/behavioral changes in addition to the AST. > Are these as a side-effect of how AST was implemented? Or are they unrelated > to the AST patch? > I think some of them make sense but I’m having a bit of a hard time > separating out the benefits of the AST (which I really like) and making other > changes to semantics w/o really understanding if they are side-effects and we > have no choice vs. we’re trying to solve for two separate items in one RFC. > Any BC breaks here we think could bite us? > > Any insight would be much appreciated. > Thanks! > Andi > > On Aug 18, 2014, at 9:41 AM, Nikita Popov wrote: > > > Hi internals! > > > > I've opened the vote on the Abstract Syntax Tree RFC: > > > >https://wiki.php.net/rfc/abstract_syntax_tree#vote > > > > Thanks, > > Nikita > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Tue, Aug 19, 2014 at 11:21 AM, Laruence wrote: > Hey: > >the problem came from zend_ast_size for 0 children node.. > Thanks for the report, this should be fixed now: https://github.com/nikic/php-src/commit/69f0deb399eec76bc8afa97fa383b08a207582fb Nikita
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Tue, Aug 19, 2014 at 11:30 AM, Laruence wrote:
> Hey:
>
> a fix could be:
> diff --git a/Zend/zend_ast.c b/Zend/zend_ast.c
> index eb35a51..f738e34 100644
> --- a/Zend/zend_ast.c
> +++ b/Zend/zend_ast.c
> @@ -33,11 +33,11 @@ static inline void *zend_ast_realloc(void *old,
> size_t old_size, size_t new_size
> return new;
> }
>
> -size_t zend_ast_size(zend_uint children) {
> +size_t zend_ast_size(int children) {
> return sizeof(zend_ast) + sizeof(zend_ast *) * (children - 1);
> }
>
> -size_t zend_ast_list_size(zend_uint children) {
> +size_t zend_ast_list_size(int children) {
> return sizeof(zend_ast_list) + sizeof(zend_ast *) * (children - 1);
> }
>
>
> my compiler must take (children -1) as a unsigned
It does, the result of the expression will be.
But the fix is imo wrong. A size cannot be negative, per se.
It would be cleaner to do:
size_t zend_ast_size(int children) {
if (children > 0) {
return sizeof(zend_ast) + sizeof(zend_ast *) * (children - 1);
} else {
// 0 or sizeof(zend_ast) + sizeof(zend_ast *) if at least one
elem is allocated (NULLed).
}
}
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hey:
a fix could be:
diff --git a/Zend/zend_ast.c b/Zend/zend_ast.c
index eb35a51..f738e34 100644
--- a/Zend/zend_ast.c
+++ b/Zend/zend_ast.c
@@ -33,11 +33,11 @@ static inline void *zend_ast_realloc(void *old,
size_t old_size, size_t new_size
return new;
}
-size_t zend_ast_size(zend_uint children) {
+size_t zend_ast_size(int children) {
return sizeof(zend_ast) + sizeof(zend_ast *) * (children - 1);
}
-size_t zend_ast_list_size(zend_uint children) {
+size_t zend_ast_list_size(int children) {
return sizeof(zend_ast_list) + sizeof(zend_ast *) * (children - 1);
}
my compiler must take (children -1) as a unsigned
thanks
On Tue, Aug 19, 2014 at 5:21 PM, Laruence wrote:
> Hey:
>
>the problem came from zend_ast_size for 0 children node..
>
>backtrace:
>
> Program terminated with signal 6, Aborted.
> #0 0x0034dc030285 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x0034dc030285 in raise () from /lib64/libc.so.6
> #1 0x0034dc031d30 in abort () from /lib64/libc.so.6
> #2 0x009d271c in _zend_mm_alloc_int (heap=0x82fff40,
> size=34359738400,
> __zend_filename=0xfc5c78
> "/home/huixinchen/opensource/github/php-src/Zend/zend_arena.h",
> __zend_lineno=69,
> __zend_orig_filename=0x0, __zend_orig_lineno=0)
> at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2003
> #3 0x009d4354 in _emalloc (size=34359738400,
> __zend_filename=0xfc5c78
> "/home/huixinchen/opensource/github/php-src/Zend/zend_arena.h",
> __zend_lineno=69,
> __zend_orig_filename=0x0, __zend_orig_lineno=0)
> at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2442
> #4 0x00a42c05 in zend_arena_alloc (arena_ptr=0x135e698,
> size=34359738376)
> at /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69
> #5 0x00a42b0e in zend_ast_alloc (size=34359738376)
> at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:27
> #6 0x00a42dcb in zend_ast_create_from_va_list (kind=1,
> attr=7, va=0x7fff2be64550)
> at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89
> #7 0x00a4303e in zend_ast_create_ex (kind=1, attr=7)
> at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:116
> #8 0x009aa0a3 in zendparse () at
> /home/huixinchen/opensource/github/php-src/Zend/zend_language_parser.y:551
> #9 0x009aed81 in compile_file (file_handle=0x7fff2be68850,
> type=8) at Zend/zend_language_scanner.l:586
> #10 0x00784de6 in phar_compile_file (file_handle=0x7fff2be68850,
> type=8)
> at /home/huixinchen/opensource/github/php-src/ext/phar/phar.c:3358
> #11 0x00a0bab2 in zend_execute_scripts (type=8, retval=0x0,
> file_count=3)
> at /home/huixinchen/opensource/github/php-src/Zend/zend.c:1301
> #12 0x0097529b in php_execute_script (primary_file=0x7fff2be68850)
> at /home/huixinchen/opensource/github/php-src/main/main.c:2564
> #13 0x00ac44b1 in do_cli (argc=31, argv=0x82ff680)
> at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:980
> #14 0x00ac55de in main (argc=31, argv=0x82ff680)
> at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:1358
> (gdb) f 6
> #6 0x00a42dcb in zend_ast_create_from_va_list (kind=1,
> attr=7, va=0x7fff2be64550)
> at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89
> 89 zend_ast *ast = zend_ast_alloc(zend_ast_size(children) TSRMLS_CC);
> (gdb) p children
> $1 = 0
>
> thanks
>
> On Tue, Aug 19, 2014 at 5:12 PM, Laruence wrote:
>> Hey:
>>
>> I find a problem while I was trying play with the patch
>>
>> Generating phar.php
>> Generating phar.phar
>>
>> Fatal error: Out of memory (allocated 786432) at
>> /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 (tried
>> to allocate 34359738400 bytes) in
>> /home/huixinchen/opensource/github/php-src/ext/phar/phar.php on line
>> 163
>> make: *** [ext/phar/phar.phar] Error 255
>> make: *** Waiting for unfinished jobs
>>
>>is this a knew issue?
>>
>> thanks
>>
>> On Tue, Aug 19, 2014 at 2:36 PM, Dmitry Stogov wrote:
>>> Hi Andi,
>>>
>>> We already discussed most of semantic changes introduced in AST patch.
>>> Most of them came from another approved RFC
>>> https://wiki.php.net/rfc/uniform_variable_syntax
>>>
>>> Thanks. Dmitry.
>>>
>>>
>>> On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote:
>>>
Hi Nikita,
I reviewed the AST RFC on my way to vote but there was something that
wasn’t clear to me.
This patch introduces some semantic/behavioral changes in addition to the
AST.
Are these as a side-effect of how AST was implemented? Or are they
unrelated to the AST patch?
I think some of them make sense but I’m having a bit of a hard time
separating out the benefits of the AST (which I really like) and making
other changes to semantics w/o really understanding if they are
side-effects and we have no choice vs. we’re trying t
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hey: the problem came from zend_ast_size for 0 children node.. backtrace: Program terminated with signal 6, Aborted. #0 0x0034dc030285 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0034dc030285 in raise () from /lib64/libc.so.6 #1 0x0034dc031d30 in abort () from /lib64/libc.so.6 #2 0x009d271c in _zend_mm_alloc_int (heap=0x82fff40, size=34359738400, __zend_filename=0xfc5c78 "/home/huixinchen/opensource/github/php-src/Zend/zend_arena.h", __zend_lineno=69, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2003 #3 0x009d4354 in _emalloc (size=34359738400, __zend_filename=0xfc5c78 "/home/huixinchen/opensource/github/php-src/Zend/zend_arena.h", __zend_lineno=69, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2442 #4 0x00a42c05 in zend_arena_alloc (arena_ptr=0x135e698, size=34359738376) at /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 #5 0x00a42b0e in zend_ast_alloc (size=34359738376) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:27 #6 0x00a42dcb in zend_ast_create_from_va_list (kind=1, attr=7, va=0x7fff2be64550) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89 #7 0x00a4303e in zend_ast_create_ex (kind=1, attr=7) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:116 #8 0x009aa0a3 in zendparse () at /home/huixinchen/opensource/github/php-src/Zend/zend_language_parser.y:551 #9 0x009aed81 in compile_file (file_handle=0x7fff2be68850, type=8) at Zend/zend_language_scanner.l:586 #10 0x00784de6 in phar_compile_file (file_handle=0x7fff2be68850, type=8) at /home/huixinchen/opensource/github/php-src/ext/phar/phar.c:3358 #11 0x00a0bab2 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixinchen/opensource/github/php-src/Zend/zend.c:1301 #12 0x0097529b in php_execute_script (primary_file=0x7fff2be68850) at /home/huixinchen/opensource/github/php-src/main/main.c:2564 #13 0x00ac44b1 in do_cli (argc=31, argv=0x82ff680) at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:980 #14 0x00ac55de in main (argc=31, argv=0x82ff680) at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:1358 (gdb) f 6 #6 0x00a42dcb in zend_ast_create_from_va_list (kind=1, attr=7, va=0x7fff2be64550) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89 89 zend_ast *ast = zend_ast_alloc(zend_ast_size(children) TSRMLS_CC); (gdb) p children $1 = 0 thanks On Tue, Aug 19, 2014 at 5:12 PM, Laruence wrote: > Hey: > > I find a problem while I was trying play with the patch > > Generating phar.php > Generating phar.phar > > Fatal error: Out of memory (allocated 786432) at > /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 (tried > to allocate 34359738400 bytes) in > /home/huixinchen/opensource/github/php-src/ext/phar/phar.php on line > 163 > make: *** [ext/phar/phar.phar] Error 255 > make: *** Waiting for unfinished jobs > >is this a knew issue? > > thanks > > On Tue, Aug 19, 2014 at 2:36 PM, Dmitry Stogov wrote: >> Hi Andi, >> >> We already discussed most of semantic changes introduced in AST patch. >> Most of them came from another approved RFC >> https://wiki.php.net/rfc/uniform_variable_syntax >> >> Thanks. Dmitry. >> >> >> On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote: >> >>> Hi Nikita, >>> >>> I reviewed the AST RFC on my way to vote but there was something that >>> wasn’t clear to me. >>> This patch introduces some semantic/behavioral changes in addition to the >>> AST. >>> Are these as a side-effect of how AST was implemented? Or are they >>> unrelated to the AST patch? >>> I think some of them make sense but I’m having a bit of a hard time >>> separating out the benefits of the AST (which I really like) and making >>> other changes to semantics w/o really understanding if they are >>> side-effects and we have no choice vs. we’re trying to solve for two >>> separate items in one RFC. >>> Any BC breaks here we think could bite us? >>> >>> Any insight would be much appreciated. >>> Thanks! >>> Andi >>> >>> On Aug 18, 2014, at 9:41 AM, Nikita Popov wrote: >>> >>> > Hi internals! >>> > >>> > I've opened the vote on the Abstract Syntax Tree RFC: >>> > >>> >https://wiki.php.net/rfc/abstract_syntax_tree#vote >>> > >>> > Thanks, >>> > Nikita >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hey: I find a problem while I was trying play with the patch Generating phar.php Generating phar.phar Fatal error: Out of memory (allocated 786432) at /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 (tried to allocate 34359738400 bytes) in /home/huixinchen/opensource/github/php-src/ext/phar/phar.php on line 163 make: *** [ext/phar/phar.phar] Error 255 make: *** Waiting for unfinished jobs is this a knew issue? thanks On Tue, Aug 19, 2014 at 2:36 PM, Dmitry Stogov wrote: > Hi Andi, > > We already discussed most of semantic changes introduced in AST patch. > Most of them came from another approved RFC > https://wiki.php.net/rfc/uniform_variable_syntax > > Thanks. Dmitry. > > > On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote: > >> Hi Nikita, >> >> I reviewed the AST RFC on my way to vote but there was something that >> wasn’t clear to me. >> This patch introduces some semantic/behavioral changes in addition to the >> AST. >> Are these as a side-effect of how AST was implemented? Or are they >> unrelated to the AST patch? >> I think some of them make sense but I’m having a bit of a hard time >> separating out the benefits of the AST (which I really like) and making >> other changes to semantics w/o really understanding if they are >> side-effects and we have no choice vs. we’re trying to solve for two >> separate items in one RFC. >> Any BC breaks here we think could bite us? >> >> Any insight would be much appreciated. >> Thanks! >> Andi >> >> On Aug 18, 2014, at 9:41 AM, Nikita Popov wrote: >> >> > Hi internals! >> > >> > I've opened the vote on the Abstract Syntax Tree RFC: >> > >> >https://wiki.php.net/rfc/abstract_syntax_tree#vote >> > >> > Thanks, >> > Nikita >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hi Andi, We already discussed most of semantic changes introduced in AST patch. Most of them came from another approved RFC https://wiki.php.net/rfc/uniform_variable_syntax Thanks. Dmitry. On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote: > Hi Nikita, > > I reviewed the AST RFC on my way to vote but there was something that > wasn’t clear to me. > This patch introduces some semantic/behavioral changes in addition to the > AST. > Are these as a side-effect of how AST was implemented? Or are they > unrelated to the AST patch? > I think some of them make sense but I’m having a bit of a hard time > separating out the benefits of the AST (which I really like) and making > other changes to semantics w/o really understanding if they are > side-effects and we have no choice vs. we’re trying to solve for two > separate items in one RFC. > Any BC breaks here we think could bite us? > > Any insight would be much appreciated. > Thanks! > Andi > > On Aug 18, 2014, at 9:41 AM, Nikita Popov wrote: > > > Hi internals! > > > > I've opened the vote on the Abstract Syntax Tree RFC: > > > >https://wiki.php.net/rfc/abstract_syntax_tree#vote > > > > Thanks, > > Nikita > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hi Nikita, I reviewed the AST RFC on my way to vote but there was something that wasn’t clear to me. This patch introduces some semantic/behavioral changes in addition to the AST. Are these as a side-effect of how AST was implemented? Or are they unrelated to the AST patch? I think some of them make sense but I’m having a bit of a hard time separating out the benefits of the AST (which I really like) and making other changes to semantics w/o really understanding if they are side-effects and we have no choice vs. we’re trying to solve for two separate items in one RFC. Any BC breaks here we think could bite us? Any insight would be much appreciated. Thanks! Andi On Aug 18, 2014, at 9:41 AM, Nikita Popov wrote: > Hi internals! > > I've opened the vote on the Abstract Syntax Tree RFC: > >https://wiki.php.net/rfc/abstract_syntax_tree#vote > > Thanks, > Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Abstract Syntax Tree
Hi internals! I've opened the vote on the Abstract Syntax Tree RFC: https://wiki.php.net/rfc/abstract_syntax_tree#vote Thanks, Nikita
