Hi,
I'll try to answer to all the emails at once.
Personally, I like the D approach more, but doc-comment proposal has its
advantages as well.
The problem that doc-comment solution is external to PHP core.
In my opinion, it should be implemented as a separate preprocessor that
reads doc-comments and generates PHP code with asserts().
I don't see how this may be implemented in PHP core itself, and I most
probably won't be evolved in development of other project.
Something similar was already implemented...
Alexander, could you please send link to implentation/dicumentation and
explain how it works (in few words).
Yasuo, I think you should describe the D proposal as well. I'm not sure if
it should be done in the same RFC (it's already big) or a new one.
Any solution would require zero-cost assert (or similar concept)
implemented in php core.
Thanks. Dmitry.
On Mon, Feb 9, 2015 at 8:52 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Guilherme,
>
> On Mon, Feb 9, 2015 at 1:44 PM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> 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
>>
>
> Thank you for the info.
>
> I had this syntax in mind.
>
> class Foo {
> __invariant() {
> // Ignored for production.
> // Check class state, every method calls invoke this method
> before/after except
> // __construct()/__wakeup()/__set_state() - after only
> // __destruct() - before only
> }
> }
>
> // Framework developer shouldn't use this. Leave this function for app
> developers.
> function __invariant() {
> // Ignored for production.
> // Invariant conditions of functions invoked for every function calls
> // to check app state. e.g. global vars,etc
> }
>
> __invariant() has similar issue as __autoload(), we may be better to
> provide generic registration
> method.
>
> Just my initial thought for discussion.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
