Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82047
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFp73XsigC9jHf7f_2sXPHPYW_N3iwof1s1i0=LF7D=pznbFLA@mail.gmail.com>
References: <CA+9eiLuNjTa8JzBgnZE5iuv5BZ4Kw4Ehk1ivxPUetNSmZ43JMw@mail.gmail.com>
	<54D37D41.2030706@hoa-project.net>
	<CAGa2bXa_E27ZK89j-C3c0-Kj8pDY4EN_8U6SQC2K19SNm46wqg@mail.gmail.com>
	<54D470FA.6000303@hoa-project.net>
	<CAGa2bXaGE3QWjGxvRadLG0btA5wd1u5bZ=AAo6WQHE_Uek8iaw@mail.gmail.com>
	<02d301d041f3$0c5f3990$251dacb0$@tekwire.net>
	<CAGa2bXafsdmTPutaYP_oyX9CbjaRcJyqk0r3_v-ud=yCiQT_SA@mail.gmail.com>
	<CAGa2bXZnBWoL7NogbQCrfy-80G7xWoD_EJT3KH3v9aPiJ68Csw@mail.gmail.com>
	<031501d04217$b393bff0$1abb3fd0$@tekwire.net>
	<CAFp73XsigC9jHf7f_2sXPHPYW_N3iwof1s1i0=LF7D=pznbFLA@mail.gmail.com>
Date: Fri, 6 Feb 2015 18:58:22 +0400
Message-ID: <CA+9eiLsKuGADEwwd1p=5ndAy4MPc2cQT9Kzkhow+Qguq6WZ1rg@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	Yasuo Ohgaki <yohgaki@ohgaki.net>, Pierre Joye <pierre.php@gmail.com>, 
	"Ivan Enderlin @ Hoa" <ivan.enderlin@hoa-project.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3ea3ce46085050e6ca60c
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--001a11c3ea3ce46085050e6ca60c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

in my opinion, RFC looks reasonable.
can you remember main arguments against it.
why it was declined?

For PHP7, it may be possible to change RFC to accept any PHP expression as
annotation value.
Then this expression may be captured as AST or evaluated to constant.

Thanks. Dmitry.



On Fri, Feb 6, 2015 at 5:35 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> Hi Dmitry,
>
> Last time we discussed was this one: https://wiki.php.net/rfc/annotations
> The ideal one was the version before:
> https://wiki.php.net/rfc/annotations?rev=3D1300089833
>
> To have this in core, we need to step back and re-evaluate how we could
> achieve 80% minimum. My original proposal was trying 95%, too much.
> We could get 80% by having a simpler implementation, something like this:
>
> <[ new Foo() ]>
> class Bar
> {
> }
>
> And all it would be required is 2 new methods as part of Reflection
> classes.
> The example could be translated into this:
>
> $bar =3D new \ReflectionClass('Bar');
> $bar->setMetadata([ new Foo() ]);
>
> var_dump($bar->getMetadata());
>
> array(1) {
>     [0] =3D> object(Foo)
> }
>
> Does that sound reasonable? It would allow us to achieve "nested
> annotations".
> However, it would not achieve a bunch of other things, like named
> parameters (you couldn't only do one or two as a constructor params...
> Foo(null, null, 'value') would be seen everywhere).
> We forget about inheritance, so metadata wouldn't be propagated to
> inherited classes, methods or properties.
> Also, if we implement in important Reflection structures, that would
> incredibly improve its power, such as: ReflectionClass, ReflectionPropert=
y,
> ReflectionMethod, ReflectionParameter and ReflectionFunction.
>
> I think this is more reasonable than my original proposal, addresses 80%
> of use cases and still help all projects around.
> Named parameters would be my next battle then... =3DD
>
>
> []s,
>
> On Fri, Feb 6, 2015 at 9:17 AM, Fran=C3=A7ois Laupretre <francois@tekwire=
.net>
> wrote:
>
>> > De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo
>> Ohgaki
>>
>> > Personally, backward compatibility is not too important.
>> > PHP5 is dead by PHP 7.2 release... This is the reason why.
>> > It's only 3 years later, only 2 years later after PHP 7.0 release.
>>
>> That's where we disagree, as I think it's most important.
>>
>> Thinking that PHP 5 is dead in 3 years is extremely na=C3=AFve IMO. You
>> probably didn't live the PHP 4/5 migration but I guess we won't have mor=
e
>> than 30 % of production servers under PHP 7 in 2018, just due to the del=
ays
>> of distros, hosting companies, and others.
>>
>> Now, suppose you're distributing a library or a framework, like Symfony,
>> Doctrine, etc. Someone tells you : "Here's the new DbC feature. You can =
use
>> it but this implies splitting your code to two independent branches and
>> maintain them in parallel until you have no PHP 5 customer anymore.". Wh=
at
>> do you think you'll do (or won't do) ?
>>
>> @Pierre,@Dmitry : you have a better vision than mine on the migration
>> process. What's your opinion on forcing software developers to maintain =
two
>> separate branches ?
>>
>> Once again, the conditions in @assert lines ARE PHP code. There's no new
>> syntax. There is no real difference between writing 'assert(<condition>)=
'
>> and '@assert <condition>', especially if the require/ensure blocks shoul=
d
>> contain 'assert' statements only.
>>
>> > What I believe is not important to you. I could be wrong.
>>
>> It is important. As I may be wrong too.
>>
>> Cheers
>>
>> Fran=C3=A7ois
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> Guilherme Blanco
> MSN: guilhermeblanco@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>

--001a11c3ea3ce46085050e6ca60c--