Hi Yasuo,
Class invariants could be done as this example:
class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}
public function doSomething($args) {
// Some complex operation over Foo instance using $args
// then...
assert $this->isValidState(): $this; // it would call
Foo::__toString() for AssertionError message
}
}
Another example of pre and post conditions:
function foo($number) {
// pre-condition
assert is_numeric($number): '...';
// Some expensive operation creating $value as response
// post-condition
assert someCheckWith($value): '...';
return $value;
}
A good explanation about use-cases can be found here
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#class-invariants
[]s,
On Sun, Feb 8, 2015 at 11:24 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Guilherme,
>
> On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Design by Contract could be used at the top of Annotation if (and only
>> if) it also had support for Interceptors. Since it could potentially be a
>> nightmare for PHP, I don't think it's time to propose something at the top
>> of another thing that is still far from being reality.
>> It would follow somehow a similar approach of what Symfony validators do:
>> http://symfony.com/doc/current/book/validation.html but it would be
>> called at possible 3 times: pre-execution, in-execution (using around and
>> bound to an external class) and post-execution.
>> However, I keep myself asking if this is a good idea. It obviously brings
>> a certain level of AOP to PHP, but I'd rather take a simplistic approach
>> such as the one suggested by Stas but with a few adjustments.
>> His approach is more inline to C and C++, but I like a more customizable
>> Java style assertion support
>> http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
>> Example:
>>
>> function foo($name) {
>> assert $name !== '': "Name must not be an empty value";
>> }
>>
>> This would be similar to this:
>>
>> function foo($name) {
>> if ($name === null) {
>> throw new AssertionError("Name must not be an empty value");
>> }
>> }
>>
>> Basically, new grammar to be supported would be something like this:
>>
>> assert_statement:
>> T_ASSERT expr ':' expr ';'
>> ;
>>
>> Where the first expr is a boolean expression and the second expr must
>> return a value (cannot be null).
>>
>> This would be a good start for PHP, even though Java does not recommend
>> to use this for argument's method check (
>> http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage),
>> but I consider that since PHP is not a strict language, we do not have the
>> same privileges by automating this check form arguments itself.
>>
>> That is my personal suggestion for DbC, which does not fully align with
>> what it was proposed, but since you asked... here it is.
>>
>
> Thank you.
> Since assert is going to have zero performance penalty, Stas proposal
> would work.
> We have to think of how invariants should be.
>
> Joe, could you add "Proposal" section to the RFC.
> https://wiki.php.net/rfc/expectations
> Currently, it does not have "Proposal" section and it's harder to
> understand what the
> RFC is. Then, could you start vote? New assert is valuable regardless of
> DbC.
>
> The RFC will encourage users to use assert(), my little concern with
> Stas's proposal
> is misuse/abuse of assert(). Stas's proposal is simplest, but I'm not sure
> if we should go
> for it or not.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
