Re: Design by Contract

On Tue, Feb 10, 2015 at 10:06 AM, Patrick Schaaf <php@bof.de> wrote: > Am 10.02.2015 07:25 schrieb "Yasuo Ohgaki" <yohgaki@ohgaki.net>: > > > > https://wiki.php.net/rfc/dbc2 > > First of all, thanks for your effort so far. > > Some questions, after reading the RFC, with no particular order: > > 1) Regarding invariants: those will be called for method calls on objects. > What about static class methods? Could we have static class invariants > (static require(.....))? Would these be called for both static and > nonstatic method calls (nonstatic method calls can change static class > state, too) > yeah, "static require()" may be a good addition. However, I don't like to invite a bicycle, we are going to borrow most related semantic from D. > 2) the pre- and postconditions could be useful for ordinary, non-OO > functions, too, to check parameters, return, and global state invariants > any function will able to use contracts. 3) I think that method preconditions are not sufficient. Pretty often, > public methods first sanitize and validate their input parameters, and > rightly so. In these cases, it would be useful to have the checking, in the > same general framework, at an arbitrary point in the function body. In > other words, assert (with an expression as the first argument, instead of a > string....). > assert() will work as well. Actually, all these addition require/return syntax is going to be just a syntax sugar that will finally call assert()s in proper order. > 4) regarding the error message second argument to the condition > definitions, it would be useful to have these not only as plain > (extrapolated) strings, but as full expressions-that-evaluate-to-string. > That would permit hooking to arbitrary private logging and log formatting > methods. > I don't think we will implement this. It may be proposed later as a DbC extension. > 5) and a bit off-topic, it would be useful to be able to declare (sic) > whole methods to be nonproduction only: Methods that will only be used in > pre/post/invariant condition expresions (or error formatters a la my point > 4) > this is also not directly related as well. Sorry, but we should define realistic target to be able to provide a working solution. We can't think about all possible and indirectly related features at once. Thanks. Dmitry. > best regards > Patrick >