From: =?utf-8?Q?Fran=C3=A7ois_Laupretre?= To: "'Sara Golemon'" References: <54E3E27B.2010903@lerdorf.com> <02c501d04b26$fd278350$f77689f0$@php.net> In-Reply-To: Subject: RE: [PHP-DEV] Scalar Type Hints v0.4 Date: Wed, 18 Feb 2015 12:05:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgGjcksIAbrU1N8Bn0wufQCkN8nOAqS8W8cB9BK8WZrdJQYQ Content-Language: fr Hi Sara, OK. I won't say you don't care. To explain, while it's not a reason, I read this at 2 AM after having = spent almost 24 hours working on this... I am happy to see I was wrong = and apologize if I have been unfair (I love 'bring it down a notch', I = didn't know the expression but I'll reuse it :). The good thing is that = it made me go to bed, when I would probably have spent the night again. If you read 'Reviving scalar type hints' posts again, especially mine's = and Zeev's, between us and to other members, they will show you what we = were aiming to, but Zeev's summary is fine too (while 'details' are = always important). I am currently writing the changes I would do to the ZPP layers and = zend_parse_parameters(). Unfortunately, I don't consider arg_info = because, IMO, using zpp is much more powerful and consistent, in the = case of a single-mode approach. I agree that, in a dual-mode approach, = it can be better to start with untyped internal functions and set type = hinting out of zpp but, in the single mode case, keeping userland and = internal available features in sync is an essential benefit, IMO again. The point of proposing to implement it via arg_info makes me afraid = because there was consensus here and, if people start arguing about zpp, = zend_parse_parameters(), or arg_info, as most don't understand the = implications very well, it can quickly go nowhere, and I understand = that's not a good argument, but we don't have much time. If it is = accepted to postpone feature freeze by one or two months, why not, but, = by now, it is March 15, very soon. Regards Fran=C3=A7ois > -----Message d'origine----- > De : php@golemon.com [mailto:php@golemon.com] De la part de Sara > Golemon > Envoy=C3=A9 : mercredi 18 f=C3=A9vrier 2015 05:26 > =C3=80 : francois@php.net > Objet : Re: [PHP-DEV] Scalar Type Hints v0.4 >=20 > Woah there, buddy. Bring it down a notch. >=20 > If you want to put forward a modified 0.1, go for it. I was stepping > forward into what I saw as a vacuum, because I don't see this > consensus you speak of. >=20 > If you feel like I'm stepping on your toes, then I'll back off, but > you don't need to accuse me of not caring. That's uncalled for. >=20 >=20 > On Tue, Feb 17, 2015 at 7:00 PM, Fran=C3=A7ois Laupretre = > wrote: > > Hi Sara, > > > > I don't know if you read the posts I exchanged with others on the = list about > scalar type hinting, but we worked hard to build a consensus on a = single > mode approach that would satisfy, say, 90% of us. And I think we got = it, step > by step, both camps moving to a common position. To summarize, it was > roughly based on 0.1, with zpp restrictions and a lot of important = 'details', like > support for additional strict-only types. Both camps seemed to agree. = I had > spent two days and two nights on it but, two hours ago, I was pretty = sure of > what I would put in the RFC, and I knew it had good chances if a FUD > campaign didn't shoot it down. > > > > Unfortunately, what I read in your message is almost exactly the = opposite > of what we had in mind. I won't take it point by point because I'm a = little > bitter tonight. Maybe tomorrow. > > > > The only positive point is that it proposes other subjects than = declare() > endless bikesheding. > > > > The negative point is that it breaks everything and puts it on the = table > again. Even what everyone agreed, like alignment on ZPP will have to = be > endlessly discussed again. And, as most don't understand the = difference and > implications of using arg_info or ZPP, it will be toxic kindergarten = again. > > > > With the 7.0 feature freeze approaching, I really don't understand = why you > did that. > > > > Anyway, you probably won't care but I find it a little unfair. I was = the first > one to propose reviving scalar type hints (hence the thread subject). = I didn't > take over Andrea's RFC because I wanted to build something different = and I > naively considered that taking over would restrict me to cosmetic = changes > before running a new vote, as it remains Andrea's RFC, not mine. I = realize I > was na=C3=AFve and too honest because you took it over formally and, = now, you > propose something really different. Now, as you know we won't probably > propose two competing RFCs, given the last flame war, you're free to > propose it the way you want. I will be less na=C3=AFve next time. > > > > Fran=C3=A7ois > > > >> -----Message d'origine----- > >> De : php@golemon.com [mailto:php@golemon.com] De la part de Sara > >> Golemon > >> Envoy=C3=A9 : mercredi 18 f=C3=A9vrier 2015 02:56 > >> =C3=80 : Nikita Popov > >> Cc : Rasmus Lerdorf; PHP internals > >> Objet : Re: [PHP-DEV] Scalar Type Hints v0.4 > >> > >> On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov = > >> wrote: > >> > This is exactly what I fear will happen with an arginfo based = approach. If > >> > even fundamental aspects like the "123" vs 123 (or true vs 1) = distinction > >> > are suppressed for internal functions, this isn't a strict typing = mode, it's > >> > just a weak typing mode with slightly different rules. > >> > > >> By the way, I realize I wasn't clear in my previous reply to you. = I > >> don't mean to dismiss your position and the proposal I put forth = was > >> just to get a feel for people's gut reactions to it. Your gut > >> reaction is clearly negative and that will be taken into account = when > >> I put up 0.4 of the RFC which may or may not look like this = proposal, > >> depending on what others have to say about it. > >> > >> -Sara > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php