Re: [PHP-DEV] RFC: Expectations
Hi Joe, I think, we may just add additional vote question. - If we like to custom exceptons as second argument? but I don't care about it, so do as you like. According to AssertException: add a note into Open Issues section. e.g. we may introduce new abstract class BaseException then make Excepton to be a child of BaseException then introduce and use for assert AssertException (direct child of BaseException) All this changes are going to be implemented as part of Engine Exception RFC. And open the vote. Thanks. Dmitry. On Thu, Feb 19, 2015 at 10:58 AM, Joe Watkins pthre...@pthreads.org wrote: Morning, I hear the concern regarding custom exceptions. Things will be used badly whatever. It's easy to imagine that in a simple application you just don't need to specify custom exceptions. But in a large codebase, being able to structure exceptions is invaluable, it gives documentation reference points and makes stack traces easier to read at a glance, because they are more meaningful. So I think we should keep the ability to throw custom exceptions. I agree about making the exception part of a new tree, so that they are not caught, so I'll just wait for that from dmitry and open the vote. Cheers Joe On Wed, Feb 18, 2015 at 5:01 PM, Dmitry Stogov dmi...@zend.com wrote: On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. I've added a few comments on the PR. Thank you very much. You found about 25 bugs :) All of them except for elseif should be fixed now. I also think printing else if instead of elseif is not a big problem. Pretty-printer may also add or remove brackets in some situations. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. Joe, this is part of your old patch. I really don't care about it. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. This may be changed together with EngineException patch. I started working on it, and I hope I'll show you results tomorrow. Thanks. Dmitry. Nikita
Re: [PHP-DEV] RFC: Expectations
On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. I've added a few comments on the PR. Thank you very much. You found about 25 bugs :) All of them except for elseif should be fixed now. I also think printing else if instead of elseif is not a big problem. Pretty-printer may also add or remove brackets in some situations. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. Joe, this is part of your old patch. I really don't care about it. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. This may be changed together with EngineException patch. I started working on it, and I hope I'll show you results tomorrow. Thanks. Dmitry. Nikita
Re: [PHP-DEV] RFC: Expectations
Morning, I hear the concern regarding custom exceptions. Things will be used badly whatever. It's easy to imagine that in a simple application you just don't need to specify custom exceptions. But in a large codebase, being able to structure exceptions is invaluable, it gives documentation reference points and makes stack traces easier to read at a glance, because they are more meaningful. So I think we should keep the ability to throw custom exceptions. I agree about making the exception part of a new tree, so that they are not caught, so I'll just wait for that from dmitry and open the vote. Cheers Joe On Wed, Feb 18, 2015 at 5:01 PM, Dmitry Stogov dmi...@zend.com wrote: On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. I've added a few comments on the PR. Thank you very much. You found about 25 bugs :) All of them except for elseif should be fixed now. I also think printing else if instead of elseif is not a big problem. Pretty-printer may also add or remove brackets in some situations. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. Joe, this is part of your old patch. I really don't care about it. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. This may be changed together with EngineException patch. I started working on it, and I hope I'll show you results tomorrow. Thanks. Dmitry. Nikita
Re: [PHP-DEV] RFC: Expectations
On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. I've added a few comments on the PR. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. Nikita
Re: [PHP-DEV] RFC: Expectations
Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC: Expectations
Updated RFC as requested. I'm just going to wait to hear what Nikita says, especially about optimizing away unqualified calls to assert. I guess this could be viewed as a BC break, it seems like quite a nice break but not sure. Will open voting when we hear from Nikita. Cheers Joe On Wed, Feb 18, 2015 at 6:23 AM, Joe Watkins pthre...@pthreads.org wrote: Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC: Expectations
OK thanks. I'm switching to another task :) Thanks. Dmitry. On Wed, Feb 18, 2015 at 10:16 AM, Joe Watkins pthre...@pthreads.org wrote: Updated RFC as requested. I'm just going to wait to hear what Nikita says, especially about optimizing away unqualified calls to assert. I guess this could be viewed as a BC break, it seems like quite a nice break but not sure. Will open voting when we hear from Nikita. Cheers Joe On Wed, Feb 18, 2015 at 6:23 AM, Joe Watkins pthre...@pthreads.org wrote: Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC: Expectations
On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC: Expectations
On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? Nikita
Re: [PHP-DEV] RFC: Expectations
Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC: Expectations
is there any penalty of catch-AssertionException-blocks? Are those eliminated in production code? Assertions should never be enabled in production code, the ability to catch (and enable by configuration) the exception serves the developer of the code during development only. The example code is bad, I'll clear this up. Cheers Joe On Mon, Feb 16, 2015 at 10:11 AM, Crypto Compress cryptocompr...@googlemail.com wrote: Hi Joe, is there any penalty of catch-AssertionException-blocks? Are those eliminated in production code? Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On Mon, Feb 16, 2015 at 10:37 AM, Joe Watkins pthre...@pthreads.org wrote:
Morning internals,
I've had mostly negative feedback on the design-by-contract idea, maybe
it's a step too far.
The expectations RFC in its current form proposes that we introduce
zero-cost assertions, which are compatible with the current assertion API.
Since this has been in discussion for quite some time, Dmitry and I
propose that the patch is rewritten for PHP7 and we get to voting as
quickly as we are able.
Please review the RFC, and provide feedback, if there are no strong
objections we will go ahead with a vote when the patch is ready, in the
coming days.
Could you improve the PHP.INI section and explain in detail what the two
new settings do? i think its somewhere implicitly described in the RFC but
there is never an explicit description. This section should probably be it.
If this ini setting affects opcode generation, have you thought about
invalidation when changing the setting?
Do I understand correctly that this is a rebuilt of the already existing
assert() functionality? What about the old behavior? You mention its
compatible, but assert() api had a switch to decide over Exceptions vs
warnings vs quietly skip.
i think the RFC should focus more on this being an improvement of assert.
It sounds like a completly new feature.
For example:
1. you are changing assert to be an opcode instead of a normal function
2. adding the new Exception mode and that it formalizes what you could do
before by using the callback mode:
assert_options(ASSERT_CALLBACK, function () { throw new
AssertionException(); });
Otherwise i am +1 on this. It fixes some annoying features of the assertion
API.
https://wiki.php.net/rfc/expectations
Cheers
Joe
RE: [PHP-DEV] RFC: Expectations
-Original Message- From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki Sent: Monday, February 16, 2015 11:45 AM To: Joe Watkins Cc: PHP internals Subject: Re: [PHP-DEV] RFC: Expectations Hi Joe, On Mon, Feb 16, 2015 at 6:37 PM, Joe Watkins pthre...@pthreads.org wrote: I've had mostly negative feedback on the design-by-contract idea, maybe it's a step too far. I think introducing strict type safety for DbC like static/compiled languages is too far. I agree. The expectations RFC in its current form proposes that we introduce zero-cost assertions, which are compatible with the current assertion API. Since this has been in discussion for quite some time, Dmitry and I propose that the patch is rewritten for PHP7 and we get to voting as quickly as we are able. Please review the RFC, and provide feedback, if there are no strong objections we will go ahead with a vote when the patch is ready, in the coming days. Big +1 Regards, From me as well. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
Hi Joe, On Mon, Feb 16, 2015 at 6:37 PM, Joe Watkins pthre...@pthreads.org wrote: I've had mostly negative feedback on the design-by-contract idea, maybe it's a step too far. I think introducing strict type safety for DbC like static/compiled languages is too far. I agree. The expectations RFC in its current form proposes that we introduce zero-cost assertions, which are compatible with the current assertion API. Since this has been in discussion for quite some time, Dmitry and I propose that the patch is rewritten for PHP7 and we get to voting as quickly as we are able. Please review the RFC, and provide feedback, if there are no strong objections we will go ahead with a vote when the patch is ready, in the coming days. Big +1 Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Expectations
Hi Martin, On Mon, Feb 16, 2015 at 6:59 PM, Martin Jansen mar...@divbyzero.net wrote: On 16.02.15 10:37, Joe Watkins wrote: Please review the RFC, and provide feedback, if there are no strong objections we will go ahead with a vote when the patch is ready, in the coming days. https://wiki.php.net/rfc/expectations I like it. But why do those two INI settings use different namespaces? Why not call zend.assertions something like assert.enable? Also I'm wondering if the default value for zend.assertions should better be 0? It requires compiler switch. If we don't have INI, then there should declare(), but it requires script modification to enable/disable. It just does not work. That's the reason why. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Expectations
Hi Joe, is there any penalty of catch-AssertionException-blocks? Are those eliminated in production code? Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/22/2013 06:20 PM, Adam Harvey wrote: On 22 October 2013 02:08, Derick Rethans der...@php.net wrote: I'm pretty convinced that expectations *without* exceptions are a good idea, as using assert (which is really eval) is a nasty thing that should be replaced, but IMO exception throwing should not be part of this feature. I agree that something to replace the eval-based assert() would be good. What if the new syntax simply respected assert_options(), and assert_options() was extended to support an explicit ASSERT_EXCEPTION control option (that presumably took an exception class name as its option value)? That seems like it would provide the exception based possibilities that some posters want while maintaining the same assertion behaviour that users are already used to by default. Adam, who apologises if this has been suggested before — this was a long set of threads and I've been busy. I'm a bit perplexed at the need to retain any compatibility with what is a poor implementation ? I've mentioned that retaining compatibility is a restriction on this implementation, I guess assuming the reasons were obvious. I've brushed over them, but to be explicit, backwards compatible means multiple ini settings, at least one userland function, module globals, and confusion. It means being able to disable and enable assertions at _runtime_, impacting the implementation and every op array that uses it in _production environments_. All these things make the implementation less suitable as an implementation of assertion and I do not see a need to restrict it in this way. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/22/2013 07:32 PM, Patrick Schaaf wrote: Am 22.10.2013 20:07 schrieb Joe Watkins krak...@php.net: You can catch exceptions, and log them. You can do that without impacting everything around you, you can do that, or whatever else you like. You can do that handling when you have only a few toplevel scripts, like when you have a setup with a small number of toplevel controllers and almost no CLI stuff around. But due to the scoped nature of try/catch you cannot reasonably / painlessly do that when you have 270 toplevel web and CLI entry points that then each need such a try/catch block. Also, there is the problem with catch (Exception) blocks, which you might easily dismiss as bad form, but which I'm sure are widespread in the field - I certainly know they are in our codebase... On the other hand, setup of an assertion-failed callback can easily go into an auto_prepend file, or into any other standard include (autoloader or something) you might have - exactly because it is something done on the global level instead of the scoped try/catch requirement. And IF you like the exception thing you can make that callback throw whatever you like - but you do not force that model on everybody. Furthermore such an assertion-failed callback has exactly the same change of looking at backtraces, so touting that as a singular feature of the exception approach is not valid. Finally, with the exception approach it is simply not true that it will completely go away in production - because these try/catch blocks will be present for any code that wants to handle the issue, and you cannot make those go away. I'm all for an assert alternative that works with expressions instead of eval, and that completely goes away in the opcode (cache) when disabled in production. best regards Patrick I was pretty explicit: used properly. We are going round in circles, discussing what assertion should be used for, again. Production code should _NOT_ have catch blocks everywhere to manage exceptions that will NEVER be thrown, obviously. assertion is a debug and development feature, if you take code to production that catches exceptions that your configuration does not allow to be thrown then that's pretty silly. assertion should be used during development, in development environments where it is enabled, by the time your code goes to production it should not suffer ExpectationExceptions and cannot anyway. I think this thread and the RFC now contains enough information regarding exceptions, it is now covered ground. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/21/2013 02:27 PM, Hochstrasser Christoph wrote: Hi Derick, This is again an RFC that does not even attempt to argue for its usefulness. This functionality was meant to replace the assert() API that currently exists in PHP, because of problems replacing it in a compatible manner. This doesn't say what is wrong with assert() or whether we *need* expect. The RFC was first proposed as a RFC to replace the assert() function with a assert keyword (which produces an opcode) in order to fix the unacceptable performance of the current assert() implementation. See also https://wiki.php.net/rfc/expectations#performance Later it was renamed to expect because the overall opinion was that changing assert() can't be done in 5.x. Yes, this RFC could state more clearly what its purpose is, but it certainly has usefulness. It's a lot faster than assert(), when turned off expect becomes a NOOP, and it doesn't rely on eval(). Morning, I'm not so good at conveying ideas; the explanation you have there is a summarized version of the java documentation of the same idea, the implementations are so similar they could be called identical. So everyone has a clear idea of how this works, here's some detail about the op array for the statement expect false;: Optimizations=On Expectations=On (DEVELOPMENT): opcodes[2] opcodes[0] - ZEND_EXPCT expression opcodes[1] - ZEND_RETURN Optimizations=Off Expectations=On: opcodes[9] opcodes[0]-opcodes[6] - ZEND_NOP opcodes[7] - ZEND_EXPCT expression opcodes[8] - ZEND_RETURN Optimizations=On Expectations=Off (PRODUCTION) opcodes[1] opcodes[0] - ZEND_RETURN Optimizations=Off Expectations=Off: opcodes[8] opcodes[0] - ZEND_JMP opcodes[7] opcodes[1]-opcodes[6] - ZEND_NOP opcodes[7] - ZEND_RETURN The same opcodes for assert(false): Optimizations=Either Assertions=Either (LEGACY): opcodes[3] opcodes[0] - ZEND_SEND_VAL string opcodes[1] - ZEND_DO_FCALL assert opcodes[2] - ZEND_RETURN When Assertions=Off opcodes[1] does not result in a call to eval, but the actual call to assert cannot be optimized, dragging down production considerably. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On Fri, 18 Oct 2013, Joe Watkins wrote: Evening Chaps, Following on from discussion regarding assertion API in PHP, the following RFC is now up for discussion: https://wiki.php.net/rfc/expectations Please do point out any missing sections or information, so that it can be clarified as quickly as possible. I hope this conveys the idea a bit clearer to everyone ? This is again an RFC that does not even attempt to argue for its usefulness. This functionality was meant to replace the assert() API that currently exists in PHP, because of problems replacing it in a compatible manner. This doesn't say what is wrong with assert() or whether we *need* expect. Besides that, why support execptions here. asserts are for testing things in development in order not to cock things up. Using exceptions for this makes very little sense. All of your examples even promote to handle exceptions and continue with excecution. If you want that, just use normal if()s with exceptions. I don't see the point of yet another syntax extension to do things you can already do just fine. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
Since this would throw exceptions, could it look like (or be) a final/abstract (although PHP doesn't allow that combo for some reason) class with static methods? Assert::isTrue($expr, $msg); That syntax is already valid (so of course there are BC issues) and I don't know how practical it is to optimize that away to nothing, but it would be more consistent with regard to throwing exceptions and would allow for a variety of different class methods. -- Matthew Leverton On Sun, Oct 20, 2013 at 8:52 PM, Joe Watkins krak...@php.net wrote: On 10/20/2013 12:15 AM, Ferenc Kovacs wrote: On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll rst...@tutteli.ch wrote: Heya, I do not know how much it concerns this RFC but I came across the following page about an extension named Expect when I was searching for RFC Expect with google. http://php.net/manual/en/book.expect.php I suppose there would be a name clash between the extension and the new expect keyword. I do not know how internals usually deal with such problems, especially if it is within an extension, but I am sure someone will know it. Cheers, Robert it was discussed on irc, there is not problem here, because the ext name and the function name can't clash, and the ext doesn't have a function with the name of expect, so everything is fine afaik. Rasmus has pointed out that there is an expect:// stream wrapper. So looks like we need a new name ?? Ideas ?? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 21/10/2013 21:36, rpar...@yamiko.org wrote: This proposal sounds a lot like exceptions to me or am I missing something :/ Could we do something like throw new expectation($expects, $message); Er, T_EXPECT will be essentially a clone of Java and Python's assert statement, but not called assert because of the existing assert() function (and backwards-compatibility is PHP's middle name). Unless you mean the similar name. Well, I don't think exception and expect can be confused (though as someone who used to use Python, I keep reading this as except, Python's equivalent to catch), though ExpectationException might be confusing. I think we should name it AssertionException. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Declaring purely static classes [Was Re: [PHP-DEV] RFC: Expectations]
Matthew Leverton wrote (on 21/10/2013):
final/abstract (although PHP doesn't allow that combo for some reason)
Final means cannot be sub-classed, abstract means must be
sub-classed; the combination would make no sense. Specifically, it
would allow completely illogical code like final abstract class Foo {
abstract public function some_method(); }
Incidentally, Java doesn't allow this combination either; this isn't PHP
being picky.
The logical declaration for a class that can only be used statically
would be static class Foo { ... }. The combination abstract static
also makes sense (for a static class with missing method bodies).
There's an ancient RFC proposing that here, but it seems it didn't get
anywhere much: https://wiki.php.net/rfc/static-classes
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
-1 to expect is a problem. expect is not a problem. Le 21 octobre 2013 à 10:42, Joe Watkins krak...@php.net a écrit : On 10/21/2013 09:57 AM, Tjerk Meesters wrote: On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner m...@php.net wrote: On 21 October 2013 10:13, Patrick Schaaf b...@bof.de wrote: Am 21.10.2013 03:52 schrieb Joe Watkins krak...@php.net: So looks like we need a new name ?? Ideas ?? abstract EXPRESSION wat? abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the short summary intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). Ah, ok well. I'd rather go for expected() or except() then... Since we're throwing around terms, here's another one: predicate expr; It should be understood by most programmers what it means (though, admittedly, it doesn't carry an obvious severity) and isn't used anywhere in the language (afaik). -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I suggest we process thusly: We need some consensus as to whether this is actually a problem or not before we get lost in suggestions ... Should we decide it's a problem then we need to decide if using the keyword expected solves the problem ... Should there still be a problem we should compile a short list and get a consensus on it before proceeding to make necessary changes. So first of all, can we get a quick +|-1 on: Using expect is a problem Using expected solves the problem We can proceed from there I think ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/21/2013 09:42 PM, Andrea Faulds wrote: On 21/10/2013 21:36, rpar...@yamiko.org wrote: This proposal sounds a lot like exceptions to me or am I missing something :/ Could we do something like throw new expectation($expects, $message); Er, T_EXPECT will be essentially a clone of Java and Python's assert statement, but not called assert because of the existing assert() function (and backwards-compatibility is PHP's middle name). Unless you mean the similar name. Well, I don't think exception and expect can be confused (though as someone who used to use Python, I keep reading this as except, Python's equivalent to catch), though ExpectationException might be confusing. I think we should name it AssertionException. I think it would be more confusing for expect to throw an AssertionException. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 22 October 2013 02:08, Derick Rethans der...@php.net wrote: I'm pretty convinced that expectations *without* exceptions are a good idea, as using assert (which is really eval) is a nasty thing that should be replaced, but IMO exception throwing should not be part of this feature. I agree that something to replace the eval-based assert() would be good. What if the new syntax simply respected assert_options(), and assert_options() was extended to support an explicit ASSERT_EXCEPTION control option (that presumably took an exception class name as its option value)? That seems like it would provide the exception based possibilities that some posters want while maintaining the same assertion behaviour that users are already used to by default. Adam, who apologises if this has been suggested before — this was a long set of threads and I've been busy. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 22 October 2013 10:32, Joe Watkins pthre...@pthreads.org wrote: On 10/22/2013 06:20 PM, Adam Harvey wrote: I agree that something to replace the eval-based assert() would be good. What if the new syntax simply respected assert_options(), and assert_options() was extended to support an explicit ASSERT_EXCEPTION control option (that presumably took an exception class name as its option value)? That seems like it would provide the exception based possibilities that some posters want while maintaining the same assertion behaviour that users are already used to by default. I'm a bit perplexed at the need to retain any compatibility with what is a poor implementation ? To be fair, I think part of the disconnect here is that I don't feel like the current implementation is particularly poor besides the eval-based API. I don't really want an assertion failure to throw an exception — if I did, I'd use an assert callback or ErrorException to do that. I want it logged so I can look at it later, and that's easily configured with the current assertion setup. I guess I'm wondering if there's a middle ground here, rather than throwing the assertion baby out with the bathwater in favour of an entirely new thing that could simply be syntax sugar sprinkled over an existing, working implementation. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On Mon, Oct 21, 2013 at 3:52 AM, Joe Watkins krak...@php.net wrote: On 10/20/2013 12:15 AM, Ferenc Kovacs wrote: On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll rst...@tutteli.ch wrote: Heya, I do not know how much it concerns this RFC but I came across the following page about an extension named Expect when I was searching for RFC Expect with google. http://php.net/manual/en/book.**expect.phphttp://php.net/manual/en/book.expect.php I suppose there would be a name clash between the extension and the new expect keyword. I do not know how internals usually deal with such problems, especially if it is within an extension, but I am sure someone will know it. Cheers, Robert it was discussed on irc, there is not problem here, because the ext name and the function name can't clash, and the ext doesn't have a function with the name of expect, so everything is fine afaik. Rasmus has pointed out that there is an expect:// stream wrapper. So looks like we need a new name ?? Ideas ?? Why ? The stream wrapper is always used in a string, so there is no parsing problem about the expect keyword. Am I missing something ? Julien.Pauli
Re: [PHP-DEV] RFC: Expectations
On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner m...@php.net wrote: On 21 October 2013 10:13, Patrick Schaaf b...@bof.de wrote: Am 21.10.2013 03:52 schrieb Joe Watkins krak...@php.net: So looks like we need a new name ?? Ideas ?? abstract EXPRESSION wat? abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the short summary intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). Ah, ok well. I'd rather go for expected() or except() then... Since we're throwing around terms, here's another one: predicate expr; It should be understood by most programmers what it means (though, admittedly, it doesn't carry an obvious severity) and isn't used anywhere in the language (afaik). -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk
Re: [PHP-DEV] RFC: Expectations
Am 21.10.2013 03:52 schrieb Joe Watkins krak...@php.net: So looks like we need a new name ?? Ideas ?? abstract EXPRESSION abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the short summary intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). best regards Patrick
Re: [PHP-DEV] RFC: Expectations
On 21 October 2013 10:13, Patrick Schaaf b...@bof.de wrote: Am 21.10.2013 03:52 schrieb Joe Watkins krak...@php.net: So looks like we need a new name ?? Ideas ?? abstract EXPRESSION wat? abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the short summary intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). Ah, ok well. I'd rather go for expected() or except() then... -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/21/2013 09:16 AM, Michael Wallner wrote: On 21 October 2013 10:13, Patrick Schaaf b...@bof.de wrote: Am 21.10.2013 03:52 schrieb Joe Watkins krak...@php.net: So looks like we need a new name ?? Ideas ?? abstract EXPRESSION wat? abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the short summary intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). Ah, ok well. I'd rather go for expected() or except() then... Expected appears to be the most suitable solution suggested so far ... I was following along with the abstract suggestion, I thought that was pretty well thought out, but a bit hard to explain why we are re-using the abstract keyword for something that is completely unrelated to abstract classes all the same ... So for those that see the problem does Expected work around it ?? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/20/2013 12:15 AM, Ferenc Kovacs wrote: On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll rst...@tutteli.ch wrote: Heya, I do not know how much it concerns this RFC but I came across the following page about an extension named Expect when I was searching for RFC Expect with google. http://php.net/manual/en/book.expect.php I suppose there would be a name clash between the extension and the new expect keyword. I do not know how internals usually deal with such problems, especially if it is within an extension, but I am sure someone will know it. Cheers, Robert it was discussed on irc, there is not problem here, because the ext name and the function name can't clash, and the ext doesn't have a function with the name of expect, so everything is fine afaik. Yeah, just to confirm, that's correct. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
