Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82044
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <031501d04217$b393bff0$1abb3fd0$@tekwire.net>
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>
Date: Fri, 6 Feb 2015 09:35:28 -0500
Message-ID: <CAFp73XsigC9jHf7f_2sXPHPYW_N3iwof1s1i0=LF7D=pznbFLA@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Dmitry Stogov <dmitry@zend.com>, 
	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=001a113fdb383573b3050e6c569b
Subject: Re: [PHP-DEV] Design by Contract
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a113fdb383573b3050e6c569b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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, ReflectionProperty,
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.n=
et>
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 more
> than 30 % of production servers under PHP 7 in 2018, just due to the dela=
ys
> 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 u=
se
> it but this implies splitting your code to two independent branches and
> maintain them in parallel until you have no PHP 5 customer anymore.". Wha=
t
> 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 t=
wo
> 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 should
> 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
>
>


--=20
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--001a113fdb383573b3050e6c569b--