Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82052
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFp73XvBC71bKcEgdRUovF-_sJP+FGTE4pYLj8-XTefDDbkwEw@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>
	<CAFp73XvBC71bKcEgdRUovF-_sJP+FGTE4pYLj8-XTefDDbkwEw@mail.gmail.com>
Date: Fri, 6 Feb 2015 19:39:22 +0400
Message-ID: <CA+9eiLu2RQdj04og=+aJ6XVk64C4ws7_-eD7Bskmh1Q34mkgtg@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=001a11339f8a7ff2b1050e6d392d
Subject: Re: [PHP-DEV] Design by Contract
From: dmitry@zend.com (Dmitry Stogov)

--001a11339f8a7ff2b1050e6d392d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think the original proposal is more consistent then the simple one.
Most probably, it just came not in right time.
In case @internals really like annotations and we came to consensus how it
should look like, I may take care about efficient implementation.

Thanks. Dmitry.

On Fri, Feb 6, 2015 at 6:19 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> 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
>> at 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 on=
e
>> 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 tha=
t
>>> no
>>> new PHP7 features might not be used in these frameworks and libraries
>>> for 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 b=
e
>>> good enough.
>>>
>>> Thanks. Dmitry.
>>>
>>> On Fri, Feb 6, 2015 at 5:17 PM, Fran=C3=A7ois Laupretre <francois@tekwi=
re.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. Y=
ou
>>> > 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
>>> 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 a=
nd
>>> > 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
>>> 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
>>> 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
>>
>
>
>
> --
> Guilherme Blanco
> MSN: guilhermeblanco@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>

--001a11339f8a7ff2b1050e6d392d--