Re: [PHP-DEV] Re: Design by Contract
Hi Stas, On Tue, Feb 10, 2015 at 9:24 AM, Stanislav Malyshev smalys...@gmail.com wrote: constraints. Type check is one of them. There are many people argue This language is secure and robust because it has _static_ types. These people are wrong. Languages can't really be secure or robust, only code implemented in these languages can, and we have witnessed many examples of vulnerable code written in pretty much any widely used language. Having strict typing may protect against some very basic errors, but in well-designed and well-tested software such errors would be rare, and in badly designed software type strictness would not save you. I agree partially. DbC encourages users to adopt secure coding best practices. Over all input/output must be controlled by programmers. This is secure programming best practice described in many security standards/guidelines. DbC encourages it. As you mentioned, well designed softwares do not have issues. DbC does not solve issues directly, but encourage good design. As a result, program becomes more secure/robust. If one have good design already, they don't have to adopt DbC for better design. Here comes DbC, once we have contracts for pre/post conditions. We are safe from calling functions with invalid parameters during development, yet we have optimum performance for production since there is zero contract checks with production mode including opcode. That assumes perfect test coverage in development, both code-wise and, more importantly, data-wise. Which is impossible. While having assert primitives that can be turned on and off looks like a useful concept to me, I don't think it is some kind of magic solution that will change everything. Over all input/output controls are important for all application. This is MUST requirement for DbC design to be successful. With DbC, functions called in deep call chains will not check input validity in production mode. Therefore, DbC adopters must control over all inputs at appropriate place (right after input was available to programmers) which is security best practice. Misuse of DbC increase risks in fact. DbC requires good design, too. It's not an automatic solution as you describe. Thank you for bring this topic. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: Design by Contract
Hi! constraints. Type check is one of them. There are many people argue This language is secure and robust because it has _static_ types. These people are wrong. Languages can't really be secure or robust, only code implemented in these languages can, and we have witnessed many examples of vulnerable code written in pretty much any widely used language. Having strict typing may protect against some very basic errors, but in well-designed and well-tested software such errors would be rare, and in badly designed software type strictness would not save you. Here comes DbC, once we have contracts for pre/post conditions. We are safe from calling functions with invalid parameters during development, yet we have optimum performance for production since there is zero contract checks with production mode including opcode. That assumes perfect test coverage in development, both code-wise and, more importantly, data-wise. Which is impossible. While having assert primitives that can be turned on and off looks like a useful concept to me, I don't think it is some kind of magic solution that will change everything. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Design by Contract
On Feb 10, 2015 3:25 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! constraints. Type check is one of them. There are many people argue This language is secure and robust because it has _static_ types. These people are wrong. Languages can't really be secure or robust, only code implemented in these languages can, and we have witnessed many examples of vulnerable code written in pretty much any widely used language. Having strict typing may protect against some very basic errors, but in well-designed and well-tested software such errors would be rare, and in badly designed software type strictness would not save you. Here comes DbC, once we have contracts for pre/post conditions. We are safe from calling functions with invalid parameters during development, yet we have optimum performance for production since there is zero contract checks with production mode including opcode. That assumes perfect test coverage in development, both code-wise and, more importantly, data-wise. Which is impossible. While having assert primitives that can be turned on and off looks like a useful concept to me, I don't think it is some kind of magic solution that will change everything. DbC is just an approach that may help to write safer programs. Of course, it's just a tool and can't gurantee anything. It's also possible to write safe code in assembler, but it's more difficult. Thanks. Dmitry. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Design by Contract
Hi Guilherme and Francois,
Could you give your ideas for these?
Thank you.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Feb 8, 2015 at 5:16 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dimitry, Francois and Guilherme,
On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Yasuo,
Following our conversation, I tried to imagine how DbC should look like
in PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
It would require only one new reserved word ensure.
Should I add D like version to the RFC? I don't care much about syntax as
long as
we have DbC.
https://wiki.php.net/rfc/dbc
Like Guilherme suggested, make some decisions first?
1- Doc comments vs. outside?
2- Keep object instance creation the same? IE: @Foo vs new Foo()
3- Is constructor the only way to inject parameters?
4- What if we have optional arguments, like: @Foo(bar, null, null,
woo)?
Suppose that you wanna fix the optional arguments by declaring names (like
this: @Foo(bar, test=woo)), doesn't it collide with PHP interests of
not supporting parametrized arguments? How would parameter skipping
proposal address this in a nicer way?
5- How would you deal with inheritance? Should a method inherit the same
annotations from parent or not?
Should we add ability to flag to inherit or not? What about overrides?
Would they be allowed? Is there a vague idea on how this concept could be
achieved?
6- Would you be possible to change annotations value at runtime?
7- Would we validate annotation arguments at all? Consider as array?
Properties of objects?
8- In case we take the approach of properties of objects... how would we
flag that a given class can/cannot be used as annotation: another
annotation, interface, any other idea?
9- Would we and/or wow would we flag that a given class could be used only
in a class and not in a method?
10- How would it be the syntax to declare a new annotation?
Since people's preferences are diverse. It might be a good idea having
pre-vote
for designs, then we may have final vote with single design.
We need some consensuses even for pre-vote.
What do you think?
Guilherme, is this the RFC you've mentioned?
Whenever you feel ready to get true, complete Annotations into core
https://wiki.php.net/rfc/annotations
Just making sure.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: Design by Contract
Hi Dimitry, Francois and Guilherme,
On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Yasuo,
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
It would require only one new reserved word ensure.
Should I add D like version to the RFC? I don't care much about syntax as
long as
we have DbC.
https://wiki.php.net/rfc/dbc
Like Guilherme suggested, make some decisions first?
1- Doc comments vs. outside?
2- Keep object instance creation the same? IE: @Foo vs new Foo()
3- Is constructor the only way to inject parameters?
4- What if we have optional arguments, like: @Foo(bar, null, null, woo)?
Suppose that you wanna fix the optional arguments by declaring names (like
this: @Foo(bar, test=woo)), doesn't it collide with PHP interests of
not supporting parametrized arguments? How would parameter skipping
proposal address this in a nicer way?
5- How would you deal with inheritance? Should a method inherit the same
annotations from parent or not?
Should we add ability to flag to inherit or not? What about overrides?
Would they be allowed? Is there a vague idea on how this concept could be
achieved?
6- Would you be possible to change annotations value at runtime?
7- Would we validate annotation arguments at all? Consider as array?
Properties of objects?
8- In case we take the approach of properties of objects... how would we
flag that a given class can/cannot be used as annotation: another
annotation, interface, any other idea?
9- Would we and/or wow would we flag that a given class could be used only
in a class and not in a method?
10- How would it be the syntax to declare a new annotation?
Since people's preferences are diverse. It might be a good idea having
pre-vote
for designs, then we may have final vote with single design.
We need some consensuses even for pre-vote.
What do you think?
Guilherme, is this the RFC you've mentioned?
Whenever you feel ready to get true, complete Annotations into core
https://wiki.php.net/rfc/annotations
Just making sure.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] RE: Design by Contract
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki Since people's preferences are diverse. It might be a good idea having pre-vote for designs, then we may have final vote with single design. We need some consensuses even for pre-vote. What do you think? What I think is that I have written a 600-line RFC, that you refuse to comment because you still hope you can impose a D-like syntax by another way. I don't agree on a pre-vote on design and, then, care about details, because that's just an artefact to get an agreement on D-like syntax before people can read and understand my proposal, and without exploring the implications of your design. Here is a fair way to proceed: I have written an RFC, trying to explore honestly every aspects of the design I'm proposing. Now, either you agree, or you write yours with the same goal in mind. Then, we may choose. That's the rule. Saying 'I don't like that' without proposing an alternative is not the right way. I won't help you get an a-priori approval, just to say thereafter that, whatever problem we find, we must stick with this design because it was pre-approved. If you write an RFC and people approve it, that's OK. Anyway, as I think DbC can be implemented without any change in the core, I'll probably implement it by myself as a zend extension. So, you can do what you want in PHP 7. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Design by Contract
Hi Francois, On Mon, Feb 9, 2015 at 12:43 AM, François Laupretre franc...@tekwire.net wrote: De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki Since people's preferences are diverse. It might be a good idea having pre-vote for designs, then we may have final vote with single design. We need some consensuses even for pre-vote. What do you think? What I think is that I have written a 600-line RFC, that you refuse to comment because you still hope you can impose a D-like syntax by another way. I don't agree on a pre-vote on design and, then, care about details, because that's just an artefact to get an agreement on D-like syntax before people can read and understand my proposal, and without exploring the implications of your design. Here is a fair way to proceed: I have written an RFC, trying to explore honestly every aspects of the design I'm proposing. Now, either you agree, or you write yours with the same goal in mind. Then, we may choose. That's the rule. Saying 'I don't like that' without proposing an alternative is not the right way. I won't help you get an a-priori approval, just to say thereafter that, whatever problem we find, we must stick with this design because it was pre-approved. If you write an RFC and people approve it, that's OK. Anyway, as I think DbC can be implemented without any change in the core, I'll probably implement it by myself as a zend extension. So, you can do what you want in PHP 7. I agree. I can also implement basic DbC feature as zend extension. It will be ugly without parser modification, but the change wouldn't be too hard. I'm sure Dmitry would do much better job than me :) You would like me to write D like version. No problem at all. If majority/consensus is annotation approach, I don't insist to have D like proposal. If you would like to choose by vote anyway, I'll write/add RFC with Dmitry's idea in mind. Dmitry, what is your opinion now? It's not mandatory, but I still prefer to have D like syntax because users can code contracts just like PHP code and get all kinds of syntax errors/etc as PHP. Would you like to have D like syntax as vote option or choose with one of annotation/D like before vote? (It seems annotation is more popular) D like design has advantage that internal functions/classes may have contracts just like user space. This may help to get better performance also. User would get consistent/similar contract errors from internal classes/functions. (I can imagine number of people against raising E_WARNING from classes, though) Guiherme, you have comprehensive annotation implementation. Could you give us your idea's about DbC and annotation? Is your idea the same as Francois's? https://wiki.php.net/rfc/dbc We don't have much time. I hope we have consensus before deadline. Thank you. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: Design by Contract
Hi all, On Mon, Feb 9, 2015 at 3:41 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey rdlow...@gmail.com wrote: First, let me say that I have voted against the current scalar types RFC. Please do not let that color your evaluation of the rest of this message ... I want to go on record (for the n-th time) as being unhappy about any proposal that forces me to use php.ini. IMHO if it doesn't work with `$ php -n` then it's not a solution, it's a hack. Yes, I understand that opcodes php -n works (Well, we have data.timezone, though) with DbC. It should execute script in production mode. can't be removed (perf, yay!) without knowing ahead of time from php.ini. But the opcode removal difficulty should not be understood as a well we just have to do it this way, situation. Instead it ought to serve as a warning sign that this is not the right answer. Type checking is not a configuration-level issue; it is a language-level issue. Shoehorning it into the .ini file is just another band-aid on a broken arm. We tend to hold new proposals to the litmus test, can this be effectively accomplished in userland already? Well, yeah, in this case it really can. Making assertions optionally throw isn't some great advancement: // I can do this now if (!is_string($str) DEBUG) throw new Exception(you bad coder bro); In order to make robust and secure apps, functions/methods is better to have constraints. Type check is one of them. There are many people argue This language is secure and robust because it has _static_ types. // I'm all for brevity but does this really need an RFC? assert(is_string($str), you bad coder bro); That's a pretty insignificant, surface-level improvement. Mostly I just disagree with the assertion (see what I did there?) that this DbC RFC is remotely the same as what the scalar types RFC is trying to accomplish. And it certainly doesn't have universal support. DbC is not surface level change. It change application/code design a _lot_. In fact, DbC controversial what we have today and paradigm change. With modularized design, the more code is consolidated, the better code is. Therefore, parameter validity is checked deep into the code for example. Since these functions are rather simple basic functions that are used by many codes, the parameter validity is checked _many_ times over and over. This slows down execution. Solution? We should get rid of simple parameter validity checks from code written in basic functions. However, if we simply get rid of the check, we'll end up with too many bugs because caller forget about callee specifications(contracts). Here comes DbC, once we have contracts for pre/post conditions. We are safe from calling functions with invalid parameters during development, yet we have optimum performance for production since there is zero contract checks with production mode including opcode. My explanation is poor. So please research what is DbC more deeply. I think you'll like it once you understand the whole concept. Many languages have DbC support, in fact almost all languages, because DbC is extremely (It's extreme for me) useful to develop fast/secure apps. I forgot to mention the most important. DbC changes application/program design and the way of programming. It changes PHP applications being more robust/secure and faster. It changes PHP application development and testing, it will be more efficient with DbC. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: Design by Contract
Hi Daniel, On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey rdlow...@gmail.com wrote: First, let me say that I have voted against the current scalar types RFC. Please do not let that color your evaluation of the rest of this message ... I want to go on record (for the n-th time) as being unhappy about any proposal that forces me to use php.ini. IMHO if it doesn't work with `$ php -n` then it's not a solution, it's a hack. Yes, I understand that opcodes php -n works (Well, we have data.timezone, though) with DbC. It should execute script in production mode. can't be removed (perf, yay!) without knowing ahead of time from php.ini. But the opcode removal difficulty should not be understood as a well we just have to do it this way, situation. Instead it ought to serve as a warning sign that this is not the right answer. Type checking is not a configuration-level issue; it is a language-level issue. Shoehorning it into the .ini file is just another band-aid on a broken arm. We tend to hold new proposals to the litmus test, can this be effectively accomplished in userland already? Well, yeah, in this case it really can. Making assertions optionally throw isn't some great advancement: // I can do this now if (!is_string($str) DEBUG) throw new Exception(you bad coder bro); In order to make robust and secure apps, functions/methods is better to have constraints. Type check is one of them. There are many people argue This language is secure and robust because it has _static_ types. // I'm all for brevity but does this really need an RFC? assert(is_string($str), you bad coder bro); That's a pretty insignificant, surface-level improvement. Mostly I just disagree with the assertion (see what I did there?) that this DbC RFC is remotely the same as what the scalar types RFC is trying to accomplish. And it certainly doesn't have universal support. DbC is not surface level change. It change application/code design a _lot_. In fact, DbC controversial what we have today and paradigm change. With modularized design, the more code is consolidated, the better code is. Therefore, parameter validity is checked deep into the code for example. Since these functions are rather simple basic functions that are used by many codes, the parameter validity is checked _many_ times over and over. This slows down execution. Solution? We should get rid of simple parameter validity checks from code written in basic functions. However, if we simply get rid of the check, we'll end up with too many bugs because caller forget about callee specifications(contracts). Here comes DbC, once we have contracts for pre/post conditions. We are safe from calling functions with invalid parameters during development, yet we have optimum performance for production since there is zero contract checks with production mode including opcode. My explanation is poor. So please research what is DbC more deeply. I think you'll like it once you understand the whole concept. Many languages have DbC support, in fact almost all languages, because DbC is extremely (It's extreme for me) useful to develop fast/secure apps. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Re: Design by Contract
First, let me say that I have voted against the current scalar types RFC. Please do not let that color your evaluation of the rest of this message ... I want to go on record (for the n-th time) as being unhappy about any proposal that forces me to use php.ini. IMHO if it doesn't work with `$ php -n` then it's not a solution, it's a hack. Yes, I understand that opcodes can't be removed (perf, yay!) without knowing ahead of time from php.ini. But the opcode removal difficulty should not be understood as a well we just have to do it this way, situation. Instead it ought to serve as a warning sign that this is not the right answer. Type checking is not a configuration-level issue; it is a language-level issue. Shoehorning it into the .ini file is just another band-aid on a broken arm. We tend to hold new proposals to the litmus test, can this be effectively accomplished in userland already? Well, yeah, in this case it really can. Making assertions optionally throw isn't some great advancement: // I can do this now if (!is_string($str) DEBUG) throw new Exception(you bad coder bro); // I'm all for brevity but does this really need an RFC? assert(is_string($str), you bad coder bro); That's a pretty insignificant, surface-level improvement. Mostly I just disagree with the assertion (see what I did there?) that this DbC RFC is remotely the same as what the scalar types RFC is trying to accomplish. And it certainly doesn't have universal support.
[PHP-DEV] Re: Design by Contract
On 2015-02-05, Dmitry Stogov dmi...@zend.com wrote:
--001a11c20e52da1ee0050e556679
Content-Type: text/plain; charset=UTF-8
Hi Yasuo,
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
It would require only one new reserved word ensure.
The assert expressions may be checked or not depending on ini directive.
It should be also possible to prevent code generation for assertions (zero
cost asserts). It was already implemented for
https://wiki.php.net/rfc/expectations
I really like the idea. D allows complete blocks that then use assert. Might
be worht investigating why they went for a block rather than one expression.
For inherited methods, only the self input-assert-expression should be
checked, and all parent output-asser-expression. This is borrowed from D
but not necessary to be repeated exactly.
I think we shouldn't introduce invariant constraints for classes now. May
be later.
I believe invariant is one of the strongest contract ideas as it goes well with
proper encapsluation and immutability like structures.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Design by Contract
Hi Dmitry,
Thank you for your time!
On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov dmi...@zend.com wrote:
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
require(input-assert-expression)
ensure(output-assert-expression)
{
...
}
It would require only one new reserved word ensure.
Less reserved word is better.
The assert expressions may be checked or not depending on ini directive.
It should be also possible to prevent code generation for assertions (zero
cost asserts). It was already implemented for
https://wiki.php.net/rfc/expectations
For inherited methods, only the self input-assert-expression should be
checked, and all parent output-asser-expression. This is borrowed from D
but not necessary to be repeated exactly.
I think we shouldn't introduce invariant constraints for classes now.
May be later.
Implementation is going to generate code for input constraint after all
RECV opcodes and before code for function body, and code for output
constraint before RETURN opcode (may be reusing implementation of
finally).
It seems fine to me overall.
I have a few questions, but I think it's better to handle discussion as I
promised.
I'll ask later!
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: Design By Contract
James Crane wrote: I've been reading and I discovered a concept called Design By Contract. I've not seen any particular libraries to aid in this particular development design process, but I was wondering if you folks had, or if there were plans to consider providing for this functionality within PHP. (A longshot, I know, but it's worth a shot.) Please refer to http://php.net/interfaces, http://php.net/spl and php-general@lists.php.net Regards, -- Michael - mike(@)php.net http://dev.iworks.at/ext-http/http-functions.html.gz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
