Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82125
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
Date: Sun, 8 Feb 2015 17:16:45 +0900
Message-ID: <CAGa2bXZ9sS9iNQgYQ5JgbYZi+iTWmFyqPOnWTWhpJOYzsPpA7g@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>, =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	guilhermeblanco@gmail.com
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2f9b4b315a2050e8f48d8
Subject: Re: Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2f9b4b315a2050e8f48d8
Content-Type: text/plain; charset=UTF-8

Hi Dimitry, Francois and Guilherme,

On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov <dmitry@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
yohgaki@ohgaki.net

--001a11c2f9b4b315a2050e8f48d8--