Re: [RFC] Scalar Type Hints v0.2

From: Date: Thu, 15 Jan 2015 19:03:08 +0000
Subject: Re: [RFC] Scalar Type Hints v0.2
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.internals 
Request: Send a blank email to internals+get-80580@lists.php.net to get a copy of this message
> On Jan 15, 2015, at 6:51 AM, Andrea Faulds <ajf@ajf.me> wrote: > > > I’m not really sure this is true. I agree that strict types aren’t entirely in keeping with > the “PHP way”. However, there are plenty of people who are against them not for that reason, but > simply because they don’t work well for them. Plus, I’m not sure strict typing causes as much of > a problem 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’t stop PHP being weakly-typed. > They just check types at function call boundaries. Think of it as a sanity check. > > > Let’s 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, > * Against, in favour of strict types: Maxime, Nikita, Markus, Marco, Leigh, Levi, Sven(?) > * In favour of strict types, not against weak types as compromise: Matthew > * Somewhat in favour: Sebastian > * In favour of allowing both approaches: Marcio, Thomas, Marco > > I apologise if I am misrepresenting anyone’s position. > > This is unlikely to be super-representative of the PHP community. However, I’m not sure I’d > say “overwhelmingly positive”. It can be easy to get confirmation bias when reading RFC threads. > > 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. > > I don’t think it’s 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. Man, oh man. I thought we finally had a proposal with 0.1 that everyone could give a thumbs up to and move forward. One that enables stronger type stability (for those who want it) and even can allow for under-the-hood optimizations. I really think we took a step back with 0.2. I think a super strict approach is really against what PHP is about. And a configuration option that significantly impacts how the language behaves is probably the worst thing we could do. I remember I bumped into something like that with Visual Basic and expression short circuiting (yes the first version didn’t have that and it became a configuration option). Completely horrible and unmaintainable. We cannot have a configuration option that changes the core language behavior. That is a no-no and there’s a good reason why languages stay away from that. And definitely disappointed that we took a step back after it seemed we could finally come to an agreement on this agonizing topic. Andi

« previous php.internals (#80580) next »