Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82050
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFp73XsSEBubkVXeXary2tLbxDoAZntdZz5N6Y1x0p7bGq_6Rg@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> <CA+9eiLvfn570PY+9yxvN8nDODyvXwFKE--LaYOm5-1RLLd7DvA@mail.gmail.com>
 <CAFp73XsSEBubkVXeXary2tLbxDoAZntdZz5N6Y1x0p7bGq_6Rg@mail.gmail.com>
Date: Fri, 6 Feb 2015 10:19:19 -0500
Message-ID: <CAFp73XvBC71bKcEgdRUovF-_sJP+FGTE4pYLj8-XTefDDbkwEw@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.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=001a113eb70e175f10050e6cf350
Subject: Re: [PHP-DEV] Design by Contract
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a113eb70e175f10050e6cf350
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Dmitry,

Actually the RFC was approved by 1 or 2 votes more than needed, but the
overall response from core maintainers was that it was overly complex,
adding features the language did not support until that point (named
parameters, short array syntax as examples), it was broken with the
proposed opcache merge (was not a trivial fix IIRC) and memory expensive.

I think a simpler approach could work now as I suggested in previous
messages. It does not add new features besides annotations itself.
We'd still have to discuss about the memory usage and where the metadata
class instances should be placed.

[]s,

On Fri, Feb 6, 2015 at 10:12 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> Dmitry,
>
> Doc comments are terrible. I really want you to spend some time looking a=
t
> what we had to do inside of Doctrine Annotations to make it work. We have
> to token_get_all() the file to be processed and track for "use"s to allow
> importing inside of doc blocks. We also had to build a top-down recursive
> parser to make it work... don't you think it's too much? As one of the
> library maintainers, I do, by heart.
>
> We have until Mar 15 to work on something and propose. I can work on it
> without any problems, but as an enthusiast of PHP, it's very frustrating
> that I spend time to make PHP better and none even care to review PRs or
> simply ignore messages on php-internals. If anyone compromise to review,
> I'd do my best to get it ready yesterday if it was possible!
>
> Thanks,
>
> On Fri, Feb 6, 2015 at 9:40 AM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>> I see your point, and, of course, it makes sense, but it also means that
>> no
>> new PHP7 features might not be used in these frameworks and libraries fo=
r
>> a
>> long time. Should we stop add new features in major releases?
>>
>> As I said, according to DbC, I'm not sure if it should be defined on
>> language level. Doc comments or annotations with external tools might be
>> good enough.
>>
>> Thanks. Dmitry.
>>
>> On Fri, Feb 6, 2015 at 5:17 PM, Fran=C3=A7ois Laupretre <francois@tekwir=
e.net>
>> wrote:
>>
>> > > De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasu=
o
>> > 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. Yo=
u
>> > 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
>> delays
>> > of distros, hosting companies, and others.
>> >
>> > Now, suppose you're distributing a library or a framework, like Symfon=
y,
>> > Doctrine, etc. Someone tells you : "Here's the new DbC feature. You ca=
n
>> use
>> > it but this implies splitting your code to two independent branches an=
d
>> > maintain them in parallel until you have no PHP 5 customer anymore.".
>> What
>> > 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 maintai=
n
>> two
>> > separate branches ?
>> >
>> > Once again, the conditions in @assert lines ARE PHP code. There's no n=
ew
>> > 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
>> >
>> >
>>
>
>
>
> --
> Guilherme Blanco
> MSN: guilhermeblanco@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>



--=20
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--001a113eb70e175f10050e6cf350--