Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80544 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89843 invoked from network); 15 Jan 2015 15:10:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2015 15:10:30 -0000 Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 74.125.82.45 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 74.125.82.45 mail-wg0-f45.google.com Received: from [74.125.82.45] ([74.125.82.45:56280] helo=mail-wg0-f45.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C6/AC-14306-468D7B45 for ; Thu, 15 Jan 2015 10:10:29 -0500 Received: by mail-wg0-f45.google.com with SMTP id y19so15499250wgg.4 for ; Thu, 15 Jan 2015 07:10:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=5ThE2C08wZg1ptifKBcgnY2e6B10FBaaxW52dG2gDDI=; b=ahuwvdZ7Tk+ouaaF6viEwm1dp/hOAxw+0abFhMklmYCFiQYc4I1TCgRAEgsNjdpMEt f4AlwHGC6MAcOTZQCAREGvUA7LKQaHr/XxL8SAotepkbfEKCWoDwMIZ/KFTmBUIq0C+H cUf4v12m6pXoYkxTDI9Dh+z46dhDsOqdEcsiE+1+nL60CI+KoKFH0dW75tXczaP6X8Dx P0YMIqhdGLMeSzJySu3UVa7xPbD/mvhmPiLxGo1HKNB17EyxHHJd32Ot2/FooOTDhrRM Vsxv3BAAXr9DMk1gxTWB7fhBSHzJ/CHPAfukdwOeJGl1sLygkrcq/zO9w/ea1tdiGzmx 95mg== X-Gm-Message-State: ALoCoQm3iaukeb8mBvVSrif8GJHfVgWGYvHR4y4s/cWlWRvru46o4zFm1tS0Piur4CI0XfEKiorxB5gY3igxM2c3CtLZnbPcoi6j3E8gX9QQFjZjzDedRPDoFW4jHeDQ7U0uez7G0VB0ojGpd0lW3SLYL561yVzxuA== X-Received: by 10.194.2.240 with SMTP id 16mr18887548wjx.108.1421334625366; Thu, 15 Jan 2015 07:10:25 -0800 (PST) References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me> In-Reply-To: <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGo6gmoLPH7aNIVeHjTN7HPWATOMwFgXHbXAiinDCoCNhsVSQIuHXg7AMzhfAQCiQHczQI0OxjrAkYga24BcDsXiwD1pNivnH63W3A= Date: Thu, 15 Jan 2015 17:10:24 +0200 Message-ID: To: Andrea Faulds Cc: RQuadling@gmail.com, Leigh , PHP Internals List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: RE: [PHP-DEV] [RFC] Scalar Type Hints v0.2 From: zeev@zend.com (Zeev Suraski) > -----Original Message----- > From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Thursday, January 15, 2015 4:51 PM > To: Zeev Suraski > Cc: RQuadling@gmail.com; Leigh; PHP Internals List > Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2 > > Hi Zeev, > > > On 15 Jan 2015, at 14:32, Zeev Suraski wrote: > > > >> Whether or not they are in the majority, a very large portion of PHP > >> developers would prefer strict typing. In particular, the most vocal > >> ones would seem to. There are also a lot of PHP developers who would > >> prefer weak typing. Thus we have a problem: either approach to scalar > >> hints will upset a large portion of the community. > > > > That's correct. As I said though, the source of the opposition is > > fundamentally different. > > The camp which opposes weak typing opposes it based on the idea that > > it doesn't behave in the way that would suit their needs. > > The camp which opposes strict typing - which incidentally includes > > most of the people who originally created the language - opposes it > > based on the assertion that it goes against the spirit of the > > language. That is equally true for the v0.2 proposal you've just > > submitted. > > I=E2=80=99m not really sure this is true. I agree that strict types aren= =E2=80=99t > entirely in > keeping with the =E2=80=9CPHP way=E2=80=9D. However, there are plenty of = people who are > against them not for that reason, but simply because they don=E2=80=99t w= ork well > for them. Plus, I=E2=80=99m not sure strict typing causes as much of a pr= oblem if > it is > off by default. Nobody is forced to use it, the language would stay > beginner- > friendly and weakly-typed. Indeed, strict type hints don=E2=80=99t stop P= HP being > weakly-typed. They just check types at function call boundaries. Think of > it as > a sanity check. > > > > >>> How do you deduce that 'nobody uses them' from the fact that some > >>> group of people said they won't? I'm sorry, but it makes no sense, > >>> especially given the positive feedback you saw on internals, making > >>> it clear that there would be in fact people using it. > >> > >> Not all of it was positive. Sure, a lot of people would use them > >> though, but I=E2=80=99ve heard quite a few developers say they wouldn= =E2=80=99t use > >> them and continue to use manual (!is_int($foo))-style assertions. > > > > Of course not all of it was positive, but it was overwhelmingly > > positive. > > Very few opposed. Someone saying they won't use it doesn't count as > > opposition. > > Let=E2=80=99s have a look. From a quick skim over the thread for v0.1: > > * In favour of weak types (or the RFC anyway): Adam, Stas, yourself, > Jordi, > Pierre, You're definitely missing Dmitry (which helped with the RFC) as well as Xinchen and Arvids from today. From past experience I believe Rasmus too. > * Against, in favour of strict types: Maxime, Nikita, Markus, Marco, > Leigh, > Levi, Sven(?) As far as I recall (maybe I'm wrong) the only one here that outright oppose= d was Nikita. Others suggested ways to improve it but didn't really oppose it. > This is unlikely to be super-representative of the PHP community. However= , > I=E2=80=99m not sure I=E2=80=99d say =E2=80=9Coverwhelmingly positive=E2= =80=9D. It can be easy to get > confirmation bias when reading RFC threads. Fair enough. > It is very clear to me that a lot of people would like strict types, and > some > people would like weak types. As to their relative numbers, I cannot say. Well, that's clear bias right here too - 'a lot' vs. 'some'. Again, I don'= t think you have a way of knowing it and based on my experience the opposite is true - but none of us truly knows. Either way, the former goes against what we created PHP around, while the latter does not. > I don=E2=80=99t think it=E2=80=99s really fair to cover only the use case= of one half of > the PHP > community. The other half counts too. This is a rather divisive issue. I disagree. PHP has never been about everything and the kitchen sink. Not only do we not strive to support everyone's taste, we actually try not to, and be somewhat opinionated on how things should be done. This issue is primarily divisive among the inner core of the PHP userbase, hardly around the millions of users out there. > > You see, PHP exists for 15-20 years now. There aren't any must-have > > features that aren't in it. No single feature we add will be used by > > everyone, and people telling us they won't use this feature shouldn't > > 'deter' us in any way. > > I don=E2=80=99t think this is true: if we are making a feature less usefu= l (and > therefore > making many people avoid it), it=E2=80=99s worth considering if that is a= problem. > If > we can easily cover the vast majority of people=E2=80=99s use cases, rath= er than > catering to only one group of people (who may or may not be the majority)= , > why don=E2=80=99t we? For the same reason we didn't introduce strict types in the countless times it came up in the past - it goes against the language's principles. > Except that is not the case for this proposal, which explicitly and > deliberately > prevents the directive affecting inclusion. The behaviour is impossible t= o > toggle at runtime, unless you=E2=80=99re using some weird extension which= lets you > edit the flag on the ZEND_DO_FCALL opcode. Fact is that people who run websites where they don't care about strict typing, can end up viewing strict type failures coming from code they don't own, which would make the app fail 'catastophically' and unpredictably. You'd have no way to turn it off (without diving to and changing the file i= n question) - because it's the code itself that turns it on - and from the user's point of view, for all practical purposes, at runtime. I agree that the scope of breakage of using a local file definition is much reduced compared to an INI entry, but it's still there. Zeev