RE: [PHP-DEV] [VOTE] Scalar Type Hints
> -Original Message- > From: Jordi Boggiano [mailto:j.boggi...@seld.be] > Sent: Sunday, February 08, 2015 8:12 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > On 07/02/2015 01:08, Sebastian Bergmann wrote: > > On 02/06/2015 10:22 PM, Nikita Popov wrote: > >> After much initial reluctance, I've voted in favor of this RFC. > > > > After reading your email, Nikita, I deleted my vote (it was no > > before). > > I will review the RFC again, with your arguments (and others) in mind > > and maybe I'll come to a different conclusion. > > Thank you for that, Sebastian. It is not a simple RFC and votes should be > thought through as it is such an old and important topic to many people. Indeed it is. I think it's very clear that this RFC represents (almost) the farthest possible position from consensus, with all of the original key designers of the language strictly opposing it, as well as many others. This is one of the most polarizing votes I ever recall here. I'm not sure whether it'll get through or not, but given the intention of this RFC was to create a proposal everyone can rally behind, it very clearly failed. We didn't have to wait for a vote by the way, it was clear from the discussion on internals@. I sincerely hope that we'll gather enough votes to prevent strict typing from making it into PHP. Last, voters should take into account that this isn't an 'either this RFC or nothing' situation. I think it's very unfortunate that the original RFC - that had zero controversy surrounding it - was never put to a vote. Clearly, it didn't give the strict camp what it wanted, but on the other hand, it introduced nothing into the language that anybody considers damaging to PHP - even in the eyes of the strict camp. That cannot be said about this RFC. I'm not sure how many of the people who support the current RFC would be equally happy (or happier) with the original one, but I suspect that it's a fair number, and we'd definitely want to put it to a vote in case the current one fails to pass (and potentially even if it does pass, to give people the opportunity to choose between having the extra strict part vs. not having it, a choice they didn't get but should have). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Sunday, February 08, 2015 9:50 PM > To: Zeev Suraski > Cc: Jordi Boggiano; internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > Zeev, > > > On 8 Feb 2015, at 19:48, Zeev Suraski wrote: > > > > Last, voters should take into account that this isn't an 'either this > > RFC or nothing' situation. I think it's very unfortunate that the > > original RFC - that had zero controversy surrounding it - was never put > > to a > vote. > > Please stop repeating this, it is blatantly false and I’ve pointed this > out > several times. It's not blatantly false, and please refrain from telling me what I can or cannot say (!) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(), which
was definitely not intended for this purpose.
Zeev
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, February 08, 2015 9:45 PM
> To: PHP Internals
> Subject: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
>
> Hi,
>
> I’m posting this in a new thread since people might (reasonably) be
> ignoring
> further responses to the [VOTE] thread.
>
> I’m considering a small change to the Scalar Type Hints RFC, specifically
> about syntax. Quite a few people have said they don’t like the declare()
> syntax, and it’s easy to see why. It’s rather verbose, it has all the
> quirks of
> declare() (such as block syntax, not respecting scope), and it’s rather
> ugly.
>
> Instead, I’m wondering if the following might be better:
>
>
> Which would be used like so:
>
>
> function foobar(): int {
> return 1.0; // error!
> }
>
> It’d be a per-file directive, so there’d be zero mixing of modes within
> one file,
> and you’d avoid the quirks of declare().
>
> It’s also a lot shorter, and it resembles Hack’s syntax:
>
>
> Of course, changing this would mean restarting the vote, but it’s only
> been
> three days, we’re less than a quarter of the way through voting.
>
> Thoughts? Thanks!
>
> (By the way, I’d appreciate it if this thread didn’t turn into yet another
> discussion of how and whether scalar type hints are a bad/good idea. We
> already have at least four threads on that subject. I’m just considering a
> specific change of syntax.)
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit:
> http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> -Original Message- > From: Matthew Leverton [mailto:lever...@gmail.com] > Sent: Sunday, February 08, 2015 11:17 PM > To: Zeev Suraski > Cc: Jordi Boggiano; PHP internals > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski wrote: > > > > proposal everyone can rally behind, it very clearly failed. We didn't > > have to wait for a vote by the way, it was clear from the discussion > > on internals@. > > > Controversial RFCs are precisely the ones that SHOULD be voted on. Not really. These should be avoided as much as possible. > Policy states that 2/3s means consensus on core language changes. The > current 63.5% isn't too far from that. Just curious, but do you have a > different number in mind for this vote? 90%? 80%? I'm well aware of it as I wrote that policy. The goal of the policy was to prevent a situation where a temporary majority can introduce features into the language that would later on be impossible to reverse. It's not by any stretch a good mechanism to solve controversial votes, which again, should ideally be avoided as much as possible. It's just that there isn't a better mechanism. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> So, controversy is where a lot of people disagree - and there were > numerous > people in the original thread who disagreed with the RFC and preferred > strict > types. I actually tallied them in a reply to Zeev (which I later quoted in > a reply > to Andi). There were almost as many people against the proposal as in > favour. This is to say nothing as to how it was received outside internals > which, from my experience on reddit, Twitter and StackOverflow, was even > less positive than internals, considerably so. > > So, I think that to say that there was “zero controversy” is certainly > stretching the truth. Really, I’m yet to see any scalar type hinting > discussions > which haven’t had some controversy. It's not stretching the truth or even slightly bending it, considering the RFC currently being voted on is a superset of that RFC. There's zero or virtually zero controversy surrounding the weak typing RFC, the one that was v0.1. The controversy wasn't (and isn't) about what was in v0.1, but rather, about what wasn't in there, namely, strict typing; Not in the contents of the v0.1 RFC itself, which, again, had zero controversy around and is effectively being voted on as an integral part of the current RFC. You have virtually all of the supporters of strict typing voting in favor of the current RFC, also voting in favor of the v0.1 elements which are an integral part of it. The way it should have went is voting on the weak typing RFC, around which there was (and probably still is) almost consensus. Right afterwards, vote on the strict elements that you added in v0.2. That would have been the one way to know what the voter base truly thinks. Right now, I believe many people are voting in favor thinking that otherwise we'd get nothing, and again - pretty much nobody is supportive of 'nothing'. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
> On 9 בפבר׳ 2015, at 01:45, Andrea Faulds wrote: > > Hi Zeev, > >> On 8 Feb 2015, at 23:24, Zeev Suraski wrote: >> >> It's not stretching the truth or even slightly bending it, considering the >> RFC currently being voted on is a superset of that RFC. > > That has no relevancy. I'll have to disagree here. It has all the relevancy in the world. I'll save the list and us all the obvious explanation, though. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
> On 9 בפבר׳ 2015, at 02:04, Jordi Boggiano wrote: > >> On 08/02/2015 23:24, Zeev Suraski wrote: >> There's zero or virtually zero controversy surrounding the weak typing RFC, >> the one that was v0.1. The controversy wasn't (and isn't) about what was in >> v0.1, but rather, about what wasn't in there, namely, strict typing; Not in >> the contents of the v0.1 RFC itself, which, again, had zero controversy >> around and is effectively being voted on as an integral part of the current >> RFC. You have virtually all of the supporters of strict typing voting in >> favor of the current RFC, also voting in favor of the v0.1 elements which >> are an integral part of it. > > By this logic, the current proposal also does not take anything away from > weak-typing proponents (which I guess I am a part of FWIW). It lets everyone > be happy in their corner. > > I don't see how this is worse than one side winning by ignoring the other. It's simple. We have two proposals here, A and B. A - has pretty much everybody agreeing with is a good idea. Nobody objects to it. It's under consensus. B - has a large number of people thinking it's alien to PHP, and has many people objecting to it. The vote is on A+B. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Monday, February 09, 2015 12:44 PM > To: Zeev Suraski > Cc: Jordi Boggiano; internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > Hi, > > > On 9 Feb 2015, at 03:48, Zeev Suraski wrote: > > > > A - has pretty much everybody agreeing with is a good idea. Nobody > objects to it. It's under consensus. > > This isn't true. I've explained why it isn't true several times. Maybe you are > suffering from confirmation bias or something, but there is no such > "consensus". Quite a few internals contributors liked v0.1. Quite a few didn't. > I've gone and evidenced this before in replies sent directly to you. Andrea, I'll make an absolute last attempt to explain what I'm saying, after that we can agree to disagree. We probably interpret the same facts differently. Fact is, there were very few people who said that weak types are *bad* (although Sebastian seems to fall in that category). The vast majority of feedback that 'opposed' weak typing, didn't really oppose weak typing at all. What it opposed was, rather, the lack of introducing strict typing. That is clearly not the same thing, which is why the fact there were people who opposed v0.1 of the RFC does not equate with people opposing weak typing, not at all. Each and every person that voted in favor of the v0.3 RFC, voted in favor of weak typing. Weak typing is not only a key element of that RFC - it's even the default behavior. In addition to everyone who voted in favor of the v0.3 RFC, many - most probably most of the people who voted against it- are in favor of the weak typing API. If you combine the two groups, you're going to get to nearly 100% support, or arguably, 'lack of opposition', to the weak typing proposal. So I stand by my comment, which has nothing to do with confirmation bias but is based on simple facts, that there's consensus (or near consensus) about weak typing being acceptable into the language. Of course, many of the people in the strict typing camp are not actively supportive of the weak typing part, but they also don't oppose it. Again, the fact they voted in favor of adding them attests to that. The controversy is exclusively around strict typing. It goes both ways - proponents of strict typing feel very passionate about having to introduce it into the language; Opponents seem to feel equally passionate about not adding them. I hope that clarifies my previous statements and put that part of the discussion to rest. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Wednesday, February 11, 2015 8:37 AM > To: Xinchen Hui; Andrea Faulds > Cc: PHP Internals > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > On 02/10/2015 07:57 PM, Xinchen Hui wrote: > >> am I wrong?! > > seems I am wrong with this, it's a false alarm... it can restore > automatically. > > Yeah, declare() doesn't span files so that isn't a problem. > > My worry is still the lack of type coercion for internal calls. There's also some pretty interesting analysis on this proposal - based on some real world experimentation - from Benjamin Eberlei - bit.ly/1vl0UED If you've voted on this RFC or intend to vote - please spend the few minutes to read through his blog post. It does a good job at actually illustrating what life would look like if this rubber ends up meeting the road. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
I said numerous times that I think that v0.1 of Andrea’s RFC was right on the mark. I’d vote in its favor in a heartbeat. It gives the exact same value from an API author’s point of view. It gives the exact same value in terms of potential performance improvements/JITting/compilation insight. But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien concept into a language that considered dynamic typing to be a core principle since its birth. Zeev *From:* guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] *Sent:* Thursday, February 12, 2015 12:46 AM *To:* Andrea Faulds *Cc:* Zeev Suraski; Rasmus Lerdorf; PHP Internals *Subject:* Re: [PHP-DEV] [VOTE] Scalar Type Hints Hi all, @Zeev and @Rasmus: Seriously, you both mentioned that consider the idea of scalar type hint, but I've never seen which idea would you consider. Andrea built a very flexible way to operate and even though I don't fully agree either, it's the best so far. This approach does have headaches, but would you ever consider a strict or weak only approach?
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> -Original Message- > From: Sebastian B.-Hagensen [mailto:sbj.ml.r...@gmail.com] > Sent: Thursday, February 12, 2015 2:11 AM > To: Zeev Suraski > Cc: guilhermebla...@gmail.com; Rasmus Lerdorf; PHP Internals > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > Hi, > > 2015-02-12 0:08 GMT+01:00 Zeev Suraski : > > It gives the exact same > > value from an API author’s point of view. > > But not from an api-consumers point of view. I didn't claim otherwise. I am claiming that piece is significantly less important, and that its negative implications outweigh its positive ones. > Without either introducing a > new set of casting/conversion rules or changing existing behavior > (**exclusively**) 'weak' typehints may be perceived as seriously crippled. > Maybe up to a point where the addition of them wouldn't be justified. I argued we should tweak the conversion rules. > > But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien > > concept into a language that considered dynamic typing to be a core > > principle since its birth. > > It's not. PHP was always open to enforce strict typing in user created > functions. Being able to do something in custom code - and having language-level syntax for it are a world a part in terms of condoned language principles. That's why proponents of this RFC are so much in its favor - and opponents are so much against. This new syntax would mean explosive growth and official encouragement for developers to place strict type checking throughout their code. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> @Zeev: I don't like being used, singling out only my blog post because it > proves your opinion, where clearly there were other posts in favour of > strict > mode typing, for exampl e ircmaxell his. Benjamin, As we discussed in personal exchanges, I really don't think I 'used' you and it certainly wasn't my intent. I thought your blog, as well as Rasmus' comments, did a good job at illustrating the shortcomings of the current RFC with real world examples - and thought (and still think) it would be a good idea for others to read it. FWIW, when people link to blog posts of mine as a recommended read I view this as a compliment, never as a negative thing. I didn't agree with the points made in Anthony's blog so I didn't link to it, but obviously, proponents of the current RFC are free to do so and did so. > You are not doing your opinion a > good service imho, by being so obviously political about this issue. I'm really not obviously or otherwise 'political' about this issue. We're dealing with technology here. Much like Andrea, Anthony and others genuinely believe that this RFC is good for PHP - me and many others believe it's bad for PHP. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, February 12, 2015 1:45 PM > To: Pavel Kouřil > Cc: guilhermebla...@gmail.com; Zeev Suraski; Rasmus Lerdorf; PHP > Internals > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > Hi, > > > On 12 Feb 2015, at 07:05, Pavel Kouřil wrote: > > > > On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds wrote: > >> > >> A number (or numeric, or num, or some other name) type hint is > something I plan to propose in a future, follow-up RFC. > >> > > > > wouldn't polymorphism (via method overloading) solve the use cases and > > be much more useful in the long run than introducing a something > > that's not a type into type hints? > > PHP already has polymorphism through its dynamic typing. I don’t see > method overloading happening any time soon. We have optional parameters > and dynamic typing, which all but eliminate the main needs for > overloading. > We’re a weakly-typed language, so overloading on scalar types might cause > unpredictable behaviour (with strict types you’d get an error sometimes, > and > that’s fine - but calling an entirely different function? Now that’s > different.) > There’s also the question of how, or if at all, method overloading could > interact with our optional parameters and dynamic typing. Finally, > overloading can lead to really poor API design: it’s not that uncommon in > some languages to see 20 different function definitions with overlapping > and > non-comprehensive subsets of a method’s behaviour, that are distinguished > only by parameter types. It’s one of my least favourite Java/C#/C++ > features > for that reason. > > In response to saying numbers are not a type: well, they are more of an > abstract type which integer and float subclass. We already have internal > facilities for converting to and from “numbers” alongside integers and > floats, > I don’t see why we can’t expose this to users. +1 Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
> On 13 בפבר׳ 2015, at 13:13, Andrea Faulds wrote: > > Hi, > >> On 13 Feb 2015, at 09:37, Patrick ALLAERT wrote: >> >> Voted "no" because of the reasons already mentioned by a bunch of others >> here. >> >> Weak type hint as presented earlier: +1 (and very good job Andrea about >> that!). >> declare(strict_types=1): -1, not only about the syntax, but also about the >> mixed mode it introduces. >> >> I'm pretty confident that this RFC will "pass" with just above 2/3 of >> majority while it could reach much more. >> >> I am pretty sure that if this RFC doesn't include a strict type mode _the >> way it is proposed_ (or even, not at all, as part of another related RFC), >> it would have some "no" converted to "yes" and would have a wider adoption, >> which is for sure a better option than relying on a voting mechanism which >> still is a supporting tool, we're not politicians after all :) > > It wouldn’t have wider adoption. Excluding a large portion of the PHP > community (which favours strict types) and giving them something which > doesn’t work for their use cases (weak types) is not going to win any fans. Any fans? Really? How about we put it to a test instead of guessing the outcome? Zeev
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> With that said, there's nothing stopping you from putting up your time to > create a competing proposal and patch. If you really believe that weak > types > are the better way forward, why not codify that? If only one of the RFCs > passes, then you have your answer. If both pass, we can simply have > another > vote to choose which to move forward with. > Competition is healthy for the community. That may be a good idea. > You also said earlier in the thread that you don't agree with the points > that I > made on my blog post (http://blog.ircmaxell.com/2015/02/scalar-types-and- > php.html). Can you share what you don't agree with (in the comments or > this > thread)? > Rasmus posted some issues, most of which I consider details in this > proposal > (declare() and lack of handling the int->float conversion > case) and I replied to them (I think they are handleable). If you have > other > disagreement, why not share? I've shared them countless times over the past decade. Strict typing exposes data that should not be interesting in the vast majority of cases and makes it prominently available for handling using native syntax. That's bound to make a lot more developers care about the internal type of scalars, and rely a lot less on PHP's dynamic typing - or, in other words, make PHP a more complex language. While Andrea's RFC does a significantly better job at hiding strict typing from uninterested parties, ultimately, mostly everyone will bump into it and have to accustom themselves to a typing behavior that's never ever existed in PHP. Two examples that come to mind are people working on shared code (not exactly an uncommon occurrence) and variables that find their way into internal strictly-typed calls, which would result in obscure messages for someone that's used to "32" and 32 to be virtually identical in PHP. > I would especially would like a response to the point that I made where I > showed 3 examples where weak hints of any type would cause subtle and > hard-to-find bugs; one of which was a high-level security risk. Languages have advantages and disadvantages. PHP's biggest advantages is developer productivity, and dynamic typing is a big component of that. Does it have disadvantages? Sure. But PHP was designed with the belief that the advantages of dynamic typing outweighs that of strict typing. In the few cases where strict type checking is needed, you have the facilities to do that in a bit of custom code. That balance of making strict type checks possible - but not at the level of native constructs - is the right balance for a dynamically typed language like PHP. You'd only add strict type checking if it's really needed, and not as an afterthought. To your examples, I'm not at all advocating the use of an arm's race to put typing information - weak or strict - everywhere. Of course, if you place a weak type hint in a situation where type conversion would pose a high security weak, it's a mistake. Keep the handling in custom code in such cases. In most scenarios, however, that's not the case. And in even more scenarios - there's no need for any kind of scalar type hinting at all. > One final side-point: In my work on Recki-CT, I learned very early on that > casts are quite expensive. When compiling mandel() from Zend/bench.php, > the implicit casts that were happening on $w2, $x and a few other vars > (which were ints) to floats for the computation added approximately 10% to > the runtime of the function. The casts in mandel2 accounted for 20% of the > runtime. Let me say that again: the > int->float conversion in the loops accounted for between 10% and 20% > of the function call. And that's not a dynamic cast (a branch based on > type), > it's a single `fild` instruction. Having the ability to statically know > that a cast > will never be needed can result in significantly faster (and easier) > native code > generation... Two points on this one: 1. PHP's motto has always been developer productivity over performance, if squeezing performance meant bothering the developer with implementation details he shouldn't care about. We prefer to work hard on getting the engine optimized, and let the developer focus on creating the business logic in the simplest possible way. By the way, in this particular case, it's possible to automatically detect that the variables in question are all floats, and have the engine automatically do it for you. It's not easy, but can be done. If we ever have JIT in PHP, it will do that automatically for developers - which is exactly PHP's spirit. 2. More importantly to our discussion, there's zero practical difference in terms of performance implications between weak and strict typing. Inside the function code, you can rely in exactly the same way - with absolute confidence that you got what you asked for. In the calling code - you can't assume anything about the value being passed and must conduct checks into it - unless it too came from a type
RE: [PHP-DEV] [VOTE] Scalar Type Hints
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 13, 2015 9:34 PM > To: Zeev Suraski > Cc: PHP Internals > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > Zeev, > > You said you disagreed with my post (meaning claims I made). I didn't ask > why you didn't like strict typing, I asked specifically why you disagreed > with > the post. Your post supports adding strict typing to PHP, and I don't, hence, I disagree with your post. > > Strict typing exposes data that should not be interesting in the vast > > majority of cases and makes it prominently available for handling > > using > > It's data you don't think is interesting. Obviously 68% of voters right > now > think it's interesting enough to support it. There's nothing obvious about it and it's almost definitely not true either. Given the way the vote went, we have no way of knowing how many people support this because they want any type of scalar type hinting, and how many support it because they truly buy into the need to have strict typing. Had we first voted on the concept of scalar type hints, and then had an option to choose between the versions - and strict was chosen - you'd be able to make that statement. That's not what happened - and we have no way of knowing how many of the voters are just getting what they need with weak typing, and are willing to live with the extra strict typing that's added to it. > The problem is not "32" and 32. The problem is "apple" and 32. A value may > work, but we're not talking about values, we're talking about types. And > yes, > in some spots and in a lot of cases having values auto-convert is amazing. > And is one of the greatest powers of PHP as a language. But in many cases > it > leads to subtle bugs. In many cases it leads to code that's REALLY hard to > reason about ahead of time. I'll paraphrase and say that the problem isn't "apple" and 32, it's "32" and 32. The latter is a heck of a lot more common than the former, and the current RFC is going to make it a much bigger hassle to handle that data. We're focusing on the edge cases and ignoring the big, working picture. But let's focus on that "apple" and 32 edge case for a moment. I've said many times, as did others, that there are ways to solve this. The PHP way of solving it would be emitting a non-fatal warning, that those that care about could act on. Heck, maybe we can even argue for a fatal error in certain 'idiotic conversion' cases. If you remember, I was in favor of revisiting the current casting rules and tweak them to perhaps be a bit less flexible and forgiving. An extremely non-PHP way of doing it, though, would be checking the zval.type field, and rejecting "32" because it's not 32. That's exactly what you get with strict types, and that's exactly why I continue to maintain this is an alien concept to PHP. > Which is why many of us want it in PHP. So we can switch back and forth, > having the parts of the application that make sense to be fully typed, > fully > typed and the parts that don't, well, not. > > In fact, this proposal, including the strict component, embraces PHP's > dynamic nature. It simply extends what existing in 5.0 for classes to the > rest > of the type system. But it gives the developer the choice. It gives the > developer the power. > > Is that, after all, what PHP is all about? Empowering people? It's about empowering people with what we think is the right way of doing things. Everything and the kitchen sink, and let the user figure out what he wants to do - has never been our approach (even if it didn't always look that way). With that approach, why not import the whole of JavaScript into PHP? And Ruby? There's obviously some awesome stuff in there. We can import their syntax verbatim. Why not empower the developer to choose? > > To your examples, I'm not at all advocating the use of an arm's race > > to put typing information - weak or strict - everywhere. Of course, > > if you place a weak type hint in a situation where type conversion > > would pose a high security weak, it's a mistake. Keep the handling in > > custom code in such cases. In most scenarios, however, that's not the > > case. And in even more scenarios - there's no need for any kind of > > scalar > type hinting at all. > > I just want to point out that this code already exists today. Meaning that > the > code you said shouldn't exist has been live for years. I'm not sure what you mean by 'shouldn't exist', but I certainly didn&#
RE: [PHP-DEV] RFC: Expectations
> -Original Message- > From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo > Ohgaki > Sent: Monday, February 16, 2015 11:45 AM > To: Joe Watkins > Cc: PHP internals > Subject: Re: [PHP-DEV] RFC: Expectations > > Hi Joe, > > On Mon, Feb 16, 2015 at 6:37 PM, Joe Watkins > wrote: > > > I've had mostly negative feedback on the design-by-contract idea, > > maybe it's a step too far. > > > > I think introducing strict type safety for DbC like static/compiled > languages is > too far. I agree. > > The expectations RFC in its current form proposes that we introduce > > zero-cost assertions, which are compatible with the current assertion > > API. > > > > Since this has been in discussion for quite some time, Dmitry and > > I propose that the patch is rewritten for PHP7 and we get to voting as > > quickly as we are able. > > > > Please review the RFC, and provide feedback, if there are no > > strong objections we will go ahead with a vote when the patch is > > ready, in the coming days. > > > > Big +1 > > Regards, >From me as well. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: I quit.
> -Original Message- > From: rdlow...@gmail.com [mailto:rdlow...@gmail.com] On Behalf Of > Daniel Lowrey > Sent: Monday, February 16, 2015 5:13 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Re: I quit. > > > The 0.1 RFC version was mentioned a lot as a good compromise by many > > people and had major support. > > Any proposal to the scalar hints problem that doesn't definitively error > out in > the `(int) "apple"` case is a non-starter for me; I believe such solutions > are > disingenuous at best and dangerous at worst. Weak type hints the way Andrea proposed them in v0.1 actually did not accept "Apple" as an int (wiki.php.net/rfc/scalar_type_hints?rev=1420209410): "†Non-numeric strings not accepted. Numeric strings with trailing characters produce a notice." † applied to both int and float type hints in case of string inputs. Judging by both this and Anthony's message from a couple of days ago giving the same Apple example, perhaps v0.1 wasn't clearly understood. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message- > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara > Golemon > Sent: Tuesday, February 17, 2015 1:58 AM > To: franc...@php.net > Cc: Philip Sturgeon; Arvids Godjuks; Jefferson Gonzalez; Rowan Collins; > PHP > internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre > wrote: > > Once again, anyone can take over version 0.3, if it is so great. Why > > don't > you do it ? > > I will play the game, stop working on my proposal, and vote 'yes' again. > > But don't ask me to do it in your place. > > > If nobody else does it, I will. > > I think Andrea's 0.3 proposal was extremely well balanced, served > everyone's > needs whether they would admit it or not, and who's only failing > (subjectively > termed) was the use of declare(). I think > declare() is fine and not nearly as ugly as some have slandered it to be, > but > I'm willing to read the winds and modify it for v0.4. > > Straw poll: > 1) int or string->float conversions, when the string looks *exactly* like a number. Given almost all of our inputs (from databases, forms, files, etc.) come in string form, that's by far the conversion that's going to give us the most trouble - and is most probably the use case that by far is going to result the largest amount of explicit casts to work around that problem. What if strict mode didn't just blindly check zval.type, but actually allowed for this one type of conversion to go through without a problem? No bool to int. No Apple to int. No "123 testing" to float. Just "32" to 32 and "37.7" to 37.7. Can the strict supporting camp consider that option? Judging by the examples brought up by proponents of v0.3, this type of conversion isn't their issue. It's the 'obviously wrong' conversions that bug them. As a secondary concern I'd put int to float conversions where no (meaningful) data is being lost, e.g. 37 -> 37.0, even though a tiny bit of accuracy is lost. Rejecting this particular conversion places us at being stricter than mostly all other languages. That said, it's a much less common conversion so I don't feel nearly as strongly about it as the string one. Last, regarding internal functions, I do agree with Rasmus and Drew. Again, judging by the examples brought up as a part of the discussion, it seems as if we gave ZPP developers a standard easy way of being a lot more picky about the types of values of particular arguments, and allowing them to do this selectively for those places that are very sensitive (e.g. curl_setopt()) would be a more suitable solution than just turning strict validation for all internal functions, which were built with very very different assumptions in mind. The biggest difference between internal functions and userland functions in the context of this RFC is that with userland functions, we're starting with a clean slate. There are no type hint definitions anywhere, developers can selectively add them as they see fit. With internal functions, we have type requirements EVERYWHERE already, but with semantics that didn't take strict typing into account at all and evolved for almost 20 years. Strict typing the way it is now would radically change these semantics overnight, and will make the adoption of strict a much bigger headache than it can be, as I believe Rasmus demonstrated. I think addressing these issues could get us a LOT closer to consensus and make a lot of those who voted 'no' on v0.3 vote yes on v0.4. Thanks for your consideration. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
In a word, yes. Have to say you're abilities to compile Zeev -> formal
declaration are pretty amazing :)
Zeev
> On 17 בפבר׳ 2015, at 08:20, Sara Golemon wrote:
>
>> On Mon, Feb 16, 2015 at 10:04 PM, Zeev Suraski wrote:
>> That syntax poll aside, I had what I hope is some sort an enlightenment, and
>> I think I know what will get me to cast my vote in favor of 'strict', as a
>> true supporter. There's one very special conversion that's too common in
>> PHP to dismiss (IMHO), and is also completely harmless in 99.999% of the
>> cases, if not strictly 100%:
>>
>> string->int or string->float conversions, when the string looks *exactly*
>> like a number. Given almost all of our inputs (from databases, forms,
>> files, etc.) come in string form, that's by far the conversion that's going
>> to give us the most trouble - and is most probably the use case that by far
>> is going to result the largest amount of explicit casts to work around that
>> problem.
>>
>> What if strict mode didn't just blindly check zval.type, but actually
>> allowed for this one type of conversion to go through without a problem?
>>
>> No bool to int. No Apple to int. No "123 testing" to float. Just "32" to
>> 32 and "37.7" to 37.7.
>>
>> Can the strict supporting camp consider that option? Judging by the
>> examples brought up by proponents of v0.3, this type of conversion isn't
>> their issue. It's the 'obviously wrong' conversions that bug them.
>>
>> As a secondary concern I'd put int to float conversions where no
>> (meaningful) data is being lost, e.g. 37 -> 37.0, even though a tiny bit of
>> accuracy is lost. Rejecting this particular conversion places us at being
>> stricter than mostly all other languages. That said, it's a much less
>> common conversion so I don't feel nearly as strongly about it as the string
>> one.
>>
>> Last, regarding internal functions, I do agree with Rasmus and Drew. Again,
>> judging by the examples brought up as a part of the discussion, it seems as
>> if we gave ZPP developers a standard easy way of being a lot more picky
>> about the types of values of particular arguments, and allowing them to do
>> this selectively for those places that are very sensitive (e.g.
>> curl_setopt()) would be a more suitable solution than just turning strict
>> validation for all internal functions, which were built with very very
>> different assumptions in mind. The biggest difference between internal
>> functions and userland functions in the context of this RFC is that with
>> userland functions, we're starting with a clean slate. There are no type
>> hint definitions anywhere, developers can selectively add them as they see
>> fit. With internal functions, we have type requirements EVERYWHERE already,
>> but with semantics that didn't take strict typing into account at all and
>> evolved for almost 20 years. Strict typing the way it is now would
>> radically change these semantics overnight, and will make the adoption of
>> strict a much bigger headache than it can be, as I believe Rasmus
>> demonstrated.
>>
>> I think addressing these issues could get us a LOT closer to consensus and
>> make a lot of those who voted 'no' on v0.3 vote yes on v0.4.
> So, if you'll permit me to summarize your message. The following
> would be palatable to you?
>
> * Lossless coercion. This would sit somewhere between strict types
> and weak types as lossy conversions (object->__toString() for objects
> passed where string expected, any->bool) would be disallowed, but
> lossless conversions (numeric strings to number types, int to float,
> whole floats to ints, numbers to strings -- But no implicit
> conversions to bools, no non-numeric strings to numerics, etc...)
>
> * Exclude internal functions from the strict switch. (Perhaps have a
> separate switch for internal functions at a later date)
>
> With option to introduce features such as the following at a later date:
>
> * Union types (e.g. function foo((int | float) $value): (bool | string) { ...
> })
> * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
> standard (like numeric), others user-definable)
>
> -Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message-
> From: François Laupretre [mailto:franc...@php.net]
> Sent: Tuesday, February 17, 2015 2:58 PM
> To: 'Sara Golemon'; 'Zeev Suraski'
> Cc: 'PHP internals'
> Subject: RE: [PHP-DEV] Reviving scalar type hints
>
> 2. It is not not about being lossless or not. People expect bool -> int to
> be
> disabled, for example, and it is not lossless.
>
> 3. It is more a question of finding a consensus about conversions which
> don't
> make sense, and disabling them. Examples include bool conversion to any
> other type and, of course, disabling trailing chars in numeric strings.
I agree. It's more of a question of eliminating potentially dangerous
conversions than just being lossless.
> 4. Once this is done, 99% of strict type proponents already said they
> would
> be OK with the so-called (not so) weak mode, making it possible to get rid
> of
> this far from perfect two-mode mechanism (actually, this two-mode
> approach more and more reminds me a great idea about bringing
> transparent Unicode support in PHP).
Even though that's not what I meant when I sent my proposal in the morning,
I've been wondering about the same thing (also with the feedback from
Dmitry). Can go an extra step from both directions, and come up with a rule
set that is stricter than the currently proposed weak hinting, but not as
strict as the currently proposed strict hinting?
Key challenge I see with that is that scalar type hinting would go farther
apart from our implicit casting rules. However, the current RFC already
aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting
"Apple" as an int). Choosing between that and having two separate modes, I
think that's the better option.
> > * Exclude internal functions from the strict switch. (Perhaps have a
> > separate switch for internal functions at a later date)
>
> This would make the feature inconsistent from an end user's pov.
>
> If a user enables strict mode, he assumes strict checks for every function
> he
> calls. *We* know that userspace and internal functions use different
> mechanisms, but the end user doesn't have to know. From his pov, a
> function
> is a function.
I think that practically speaking, that is incorrect, at least from my
experience with PHP developers. They do differentiate between built-in
functions and userland functions. There are some fundamental differences
between the two (being able to find their code, step into them in a
debugger, find docs on php.net, etc.).
As I mentioned earlier, the fundamental difference between built-in
functions and userland functions in the context of our discussion is that if
we introduce userland type hints, nothing happens before people change their
code, and make (hopefully) informed decisions about what type hints to add,
if any. No such luck with built-in functions, which have type information
associated, built collectively over the last two decades. As Rasmus
demonstrated, flipping that switch on for built-in functions results in a
lot of work to 'clean' the code up, but you end up with having code that's
not necessarily any better. That said, it's quite possible that the
situation will be much improved if & when we implement the less-strict rules
we're proposing here, which would accept "32" as an integer or 37 as a
float.
If we still see that employing the strict(er) rules is very noisy with
internal functions, a more appropriate option may be introducing new types
into ZPP, that would correspond to the new rules we introduce in the
userland type hints, and requiring extension authors to explicitly move to
them where they believe it's appropriate. That will allow extension authors
to make their choice regarding their APIs, similarly to the process that
will happen in userland.
> So, from all these arguments, I now think that strict types, as defined in
> 0.3,
> are not the best solution.
>
> > With option to introduce features such as the following at a later date:
> >
> > * Union types (e.g. function foo((int | float) $value): (bool |
> > string) { ... })
> > * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
> > standard (like numeric), others user-definable)
>
> As I told Zeev, union types can be kept for the future if we don't go the
> nullable road, as it would be too confusing making 'string|null' and
> '?string'
> synonyms.
I think we all agree about that.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message- > From: Andrey Andreev [mailto:n...@devilix.net] > Sent: Tuesday, February 17, 2015 4:49 PM > To: Zeev Suraski > Cc: franc...@php.net; Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > Hi, > > On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski wrote: > > I agree. It's more of a question of eliminating potentially dangerous > > conversions than just being lossless. > > > > Agreed as well. However, while bool -> int conversion one of the reasons > why many people want strict type-hints, it also often makes sense and is > quite widespread. There's no silver bullet for that problem. I'm not sure we need a silver bullet. If the conversion and acceptance rules are clear and reasonable, it's an entirely valid outcome that in cases where both int and bool are equally acceptable, you won't use a type hint but rather explicitly cast to int inside the function. > But is it the best solution? The dual-mode approach was suggested because > there is need and demand for *two* kinds of type-hinting. Most of the > controversy and criticism came from the fact that introduces a switchable > mode, while most of the praise received was due to somebody finally > proposing *both* solutions at the same time. Every option has pros and cons. Since it's clear beyond a reasonable doubt that we can't all agree on purely weak type hints and equally on purely strict type hints, it becomes a question of what is the right compromise. Adding both - which at least from my point of view has major drawbacks (too prominent zval.type exposure; complexity of two systems; internal functions issue). Creating something in between that would handle most if not all of the use cases the strict camp brought up, while not (IMHO) overly focusing on zval.type and making things a lot more noisy/complex for built-in functions - is a better direction, whose advantage - I think - outweigh its disadvantages. > > If we still see that employing the strict(er) rules is very noisy with > > internal functions, a more appropriate option may be introducing new > > types into ZPP, that would correspond to the new rules we introduce in > > the userland type hints, and requiring extension authors to explicitly > > move to them where they believe it's appropriate. That will allow > > extension authors to make their choice regarding their APIs, similarly > > to the process that will happen in userland. > > > > And that brings us back to square one ... Expose only 1 tool to userland, > but > then give two options to the much less-populated crowd of extension > developers. That doesn't make sense to me. First, let us hope that the situation will be much better to a level that we don't need to go in that direction :) But that said, I don't quite see it in the same way. Internal functions already commonly use a lot more advanced type checking than is commonly found in userland functions. Functions that behave differently depending on the type of argument you pass, on the number of arguments, etc. While technically it's possible to achieve in userland, it's a lot less common. So while I do see an issue here, I don't think it's *that* bad if it has to come to that. Unless we find out our rules work nicely out of the box for internal functions (which I'm still somewhat hopeful for) - there's no way to reconcile the fact that internal functions come with this long history of having detailed type data, while userland functions do not... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Tuesday, February 17, 2015 5:48 PM > To: Zeev Suraski > Cc: franc...@php.net; Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > Zeev et al, > > Because it > **wasn't** a compromise (neither side had to give up anything). It gave > both > sides exactly what they want and need while letting them work together > transparently. If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. It's not unique to this RFC either; There's a reason we don't accept all proposals, including countless ones that have zero compatibility/performance issues, just because we don't think they're a good fit for the language. Regarding your point about static analyzers, based on what I saw on this list it hardly seems that this is the main reason most proponents of strict types are interested in them. I, for one, think developer productivity is a lot more important than making life easy for static analyzers, and static analyzers should be designed around the language, not vice versa. I urge you to consider the fact that the solution that 'gives everyone what they wanted' is hardly that at all, and we're trying to find a potential compromise that will hopefully have a lot fewer people objecting to it. If we succeed, not everyone will get everything they want, but hopefully a lot more people will be able to join the yes vote. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
> On 17 בפבר׳ 2015, at 18:32, Andrey Andreev wrote: > > Hi, > >> On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski wrote: >> >> If it gave both sides exactly what they wanted, how come it generated so >> much objection? >> >> Simply put, because it absolutely doesn't give both sides what they wanted. >> Many (most?) of those who opposed it opposed it because they believe making >> zval.type as prominently available as the RFC did is bad for PHP. >> Consequently, this whole 'adding both gives everyone what they want' is >> simply wrong. > > I agree that it doesn't give everybody what they want - it only gave > weak hint supporters *all* that they want. Andrey, I'm a weak typing supporter; I want PHP to never make it easy at the language level to treat "32" and 32 differently; The RFC did exactly that. -> The v0.3 RFC didn't give weak hint supporters everything they wanted. QED. > Many also objected because strict typing was only opt-in and could > never affect the caller's code unless the caller explicitly declares > that they want to do that. You're ignoring that and you're twisting it > the other way around. It's enough to provide one counter example to disprove an assertion - the assertion that the v0.3 RFC gave everyone what they wanted - and I provided the one I can personally attest to. I certainly didn't claim strict typing supporters got everything they wanted, so I'm not sure why I'm twisting anything. If anything, you're only making the point that the v0.3 RFC doesn't give everyone what they want stronger. I think the options we're discussing here take us away from this zero sum game, provides benefits to both schools of thought, and it seems to me as if you were open to it. I'd much rather we invested our energies there! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> Yes, I already know that. > The difference, and why I keep pointing that out, is that me and many > others > want strict typing for our own reasons (but still in its entirety instead > of as a > limited mode) and most of us don't even care if you getting weak typing > for > your own usage. You can't work towards consensus if your target is to > prevent the opposing group of getting what they want. I see both as > valuable > tools for different jobs and I want to have more tools at my disposal, > while > you're trying to tell me that I should use only one tool for everything. First, it's very important to understand that my target is to prevent the opposing group from getting what they want. I'm really not sadistic :) My reasons were obviously different and worked towards a different goal. Much in the same way that people who vote against an RFC - one of the countless that were voted against - don't do that to hurt the ones who support it. They do it because they think adding it would bring negative consequences. I never believed the 'You don't have to use it' as a silver bullet explanation for why it's OK to add features with potentially negative implications. The good news is that I think that in many ways the ideas we're toying with right now are better for the strict-type camp, especially if we end up going for just one mode, and meet roughly mid-way in terms of strict and weak - which I think is doable. The biggest gripes strict campers had with weak mode are gone in this proposal, and unlike v0.3 - that would actually be the default (and only) behavior, which is a big gain for the strict campers. And the most prominent features of weak typing are kept (dynamic type conversion where it makes sense), hopefully making the weak campers happy too. > But you implied that most objections were from people who don't want > strict > typing in PHP at all. And I disagree with that because it's a speculation, > which > in turn you are using to favor your weak-hints-only case (hence, twisting > it in > another direction). I didn't imply it now (at least I certainly didn't intend to). I did outright say it a week or two ago, and still believe that's the case but reached the conclusion that none of us would gain anything from further discussing it. We won't know unless we start actually polling the people who voted and ask, which we're not going to do, and we're obviously not going to convince each other. Much more importantly, it at least *seems* as if we have a direction for something that a very wide audience may rally behind. Let's focus on that! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
> -Original Message- > From: Nikita Popov [mailto:nikita@gmail.com] > Sent: Wednesday, February 18, 2015 3:06 AM > To: Rasmus Lerdorf > Cc: Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Scalar Type Hints v0.4 > > The inability to implicitly cast "123" to int is pretty much the KEY > distinction > between weak and strict scalar typehints (those pesky value-dependent type > checks). If the strict typing mode doesn't offer this, what's the point at > all? I am wondering what the point is indeed with preventing "123" to 123. So far, all the concrete use cases people brought up had to do with "Apple" or "100 dogs", but nobody ever seems to be able to explain why converting "123" to 123 is likely to be a problem real world. Is it really just static analyzers? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
> Consider the following signature:
>
> function foo(int $bar) {}
>
> In the case of a *string* representation of a hexadecimal number, the
> following would error only on the last iteration with a weak hint, and on
> the
> very first if it was a strict hint:
>
> for ($i = 0; $i < 11; $i++)
> {
> foo(base_convert($i, 10, 16));
> }
>
> And when I said leading zeros, I was talking about fixed-length string
> identifiers such as '001', '002', etc. where you may *unintentionally*
> pass
> such a value to a function that deals with ... quantities, for example. A
> strict
> hint in that case would immediately catch this logical error while a weak
> hint
> would silently ignore the leading zeros and will happily treat the value
> as an
> integer. Again, the precondition here is that it's not an integer value
> that
> happens to be stored as a string, but a non-integer value that just looks
> like
> an integer.
Thanks the example Andrey, it's helpful.
My goal with asking for these use cases isn't to claim that they never
exist, and I certainly don't want to get into a theological discussion. My
goal is to try and figure out whether many, if not all, proponents of strict
typing would be willing to live with a compromise on single set of rules,
that on one hand would be a lot stricter than what was proposed for weak
typing in the v0.3 RFC (bool->anything fails, any string that's not strictly
looking like a number incl. "100 dogs" -> int/float fails, float->int
fails), but on the other hand, would allow certain lossless conversions
(numeric string -> int/float, int->float, toString() to string, etc.) to
work.
When people from both schools of thought (strict/weak) come to evaluate this
possibility, remember that we don't need a solution that works in 100.0% of
the cases. Edge cases, again, be them strict or weak, can always be
implemented with a bit of custom code inside the function - the important
thing is to get a system that addresses the vast majority of cases.
Thanks!
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
> -Original Message-
> From: Robert Stoll [mailto:p...@tutteli.ch]
> Sent: Wednesday, February 18, 2015 1:14 PM
> To: 'Zeev Suraski'; 'Nikita Popov'; 'Rasmus Lerdorf'
> Cc: 'Sara Golemon'; 'PHP internals'
> Subject: AW: [PHP-DEV] Scalar Type Hints v0.4
>
> > -Ursprüngliche Nachricht-
> > Von: Zeev Suraski [mailto:z...@zend.com]
> > Gesendet: Mittwoch, 18. Februar 2015 08:00
> > An: Nikita Popov; Rasmus Lerdorf
> > Cc: Sara Golemon; PHP internals
> > Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
> >
> > I am wondering what the point is indeed with preventing "123" to 123.
> > So far, all the concrete use cases people brought up had to do with
> > "Apple" or
> > "100 dogs", but nobody ever seems to be able to explain why converting
> "123"
> > to 123 is likely to be a problem real world. Is it really just static
> > analyzers?
> >
>
> Strict mode is useful in the sense that it prevents unnecessary implicit
> conversions (which are costly) and it improves readability.
> Following an example:
>
> function foo(string $x, int $y){
> bar(1);
> return strstr($x,"hello", $y);
> }
>
> function bar(float $a){}
>
> After adding the implicit conversions the code would look as follows:
>
> function foo(string $x, int $y){
> bar((float) 1);
> return strstr($x, "hello", (bool) $y); }
>
> function bar(float $a){}
>
> In strict mode the original code would not be valid (rightly so IMO). Just
> from
> reading the original code I would suspect that strstr expects some kind of
> an
> offset (hence the int), therefore strict mode probably revealed a bug.
There are two things I'm not so clear about in what you're saying.
It seems that the 2nd sample adds explicit casts and not implicit casts.
Explicit casts are actually use a much more aggressive ruleset than even the
ruleset in the v0.3 RFC, in the sense that they'd happily convert "Apple"
into (float) 0.0, if you do an explicit (float) cast. They (almost) can't
fail.
Secondly, I think there aren't any common situations where strict typing (in
the form of zval.type comparison) would be any less costly than weak typing.
The difference is really between failure (abort in case there's a type
mismatch in strict) and success (convert to the requested type). The
conversion that may happen in the weak scenario is no costlier than an
explicit cast, probably a tiny bit less actually.
Again, in my opinion pushing users towards explicit casts - which have much
more lax rules than the ones proposed in v0.3, let alone the ones we're
currently considering, will defeat the purpose and actually make finding
bugs harder.
> And if not, then one can add the conversion manually. However, this is not
> as
> trivial as it sounds. Personally I think it would only make sense to have
> strict
> mode in PHP if the user had more strict conversion functions at hand. What
> is
> the benefit of the following? if the conversion to int is as sloppy as
> today
> then one does not gain anything from the strict mode IMO:
>
> function foo(int $x){}
> foo( (int)$_GET["bla"]);
I agree, but changing the rules of explicit casts is a *huge* change and BC
break. If we do implement the single-mode, stricter-than-pure-weak and
weaker-than-pure-strict ruleset, we could introduce a new set of conversion
functions, along the lines of safe_int(), that would follow the same rules
as the corresponding type hints (i.e. accept (int) 32, (string) "32", but
not (float) 32.7, or (string) "32 dogs").
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
> -Original Message- > From: Pádraic Brady [mailto:padraic.br...@gmail.com] > Sent: Wednesday, February 18, 2015 4:50 PM > To: Andrey Andreev > Cc: Zeev Suraski; Nikita Popov; Rasmus Lerdorf; Sara Golemon; PHP > internals > Subject: Re: [PHP-DEV] Scalar Type Hints v0.4 > > Hi all, > > On 18 February 2015 at 09:14, Andrey Andreev wrote: > > Hi, > > > > On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski wrote: > >> I am wondering what the point is indeed with preventing "123" to 123. > >> So far, all the concrete use cases people brought up had to do with > >> "Apple" or > >> "100 dogs", but nobody ever seems to be able to explain why converting > "123" > >> to 123 is likely to be a problem real world. Is it really just > >> static analyzers? > >> > > > > I too am curious about the potential issue with "123" to 123 > > specifically, although it could be seen as a subset of another problem > > that is solved with strict hints - numeric-character string > > identifiers being erroneously treated as integers. > > However, “123” is exceptional. It’s redefining an integer as “ an integer > or a > string comprised wholly of digits without leading zeroes, with an optional > leading hyphen, and representing an integer up to PHP_INT_MAX”, i.e. an > integer or a string with a real number that be made an integer without > loss. > No other string need apply. That’s not strict-strict typing (there’s > coercion) > but it’s probably strict enough to pass muster (it’s one single obvious > coercion under limited circumstances). > Then again, it’s an exception that requires a long sentence. There are shorter ways to define this exception - not in a formal way perhaps, but that gets the point across - something like 'a string that looks like an integer', and we can throw in 'and that can be converted with no data loss'. Of course, writing docs isn't one of my strong points :) > It’s just not clear, > to me, if this is the sole intended exception, or if that sentence needs > to be > expanded to a paragraph. A section? Are we going to need a chapter? I’m > assuming octals-in-a-string are a no-go to be coerced whereas others might > just see an integer with superfluous leading zeroes. It's not the sole exception, but it's one of the most important one in my opinion. The rationale would be conversions that can be made without meaningful data loss or creating data that wasn't there. That means that "42" can coerce into int, and "42.2" can coerce into float, and int can coerce into float - but not vice versa. That means that boolean will not coerce into anything, because turning it into an integer, float or string 'invents' data that wasn't there. A somewhat sticky points is coercion into boolean. We need to figure this one out, and hopefully we can come up with something most people can agree to. Another open question would be coercion of float/int into string. This particular point might be good for a secondary vote, as I imagine people from both camps won't see this particular conversion as a major deal-breaker for them (could be wrong). Getting the point across could be made using a table very similar to the one in wiki.php.net/rfc/scalar_type_hints#behaviour_of_weak_type_checks (as you seemed to suggest) - of course modified to reflect the much stricter ruleset we're talking about here. I don't imagine that even a formal declaration would require a whole chapter. Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
> On 18 בפבר׳ 2015, at 19:50, Rasmus Lerdorf wrote: > > On 02/18/2015 08:51 AM, François Laupretre wrote: >>> De : Pádraic Brady [mailto:padraic.br...@gmail.com] >>> >>> Careful, it helps not to call folk "radicals" if you intend to pursue >>> a compromise with them ;). >> >> Sorry, english is not my native language, and 'radical' may be offensive. >> >> I was just looking for a word for people who consider providing two modes is >> a pre-requisite to any discussion. >> >>> I wouldn't necessarily mind int->float - it's lossless assuming one way >>> only. >> >> It's lossless but it kills the 'strict' position. It can be claimed, one >> hand on the heart, this will be the only exception but, as use cases and >> side effects accumulate, we all know it will finish as a bunch of exceptions >> to a no-more strict mode, adding confusion where it is not needed. I guess >> the next one would be (int -> bool), and the rest would follow. > > We need to keep in mind that int->float isn't technically lossless. We > have a 53-bit IEEE754 mantissa to take account for here, so it is only > lossless for values below 36028797018963966 or so. We can limit ourselves to values below that limit. If you deal with values above it, be explicit about casting. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: Thursday, February 19, 2015 9:00 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Reviving scalar type hints > > On 02/17/2015 01:30 PM, Zeev Suraski wrote: > >> Yes, I already know that. > At this point, if I could rephrase the "camps" a bit I see two different > sets of > priorities: > > 1) PHP should do what seems "obviously safe" to do, to make life easiest > for > developers. That is, it's patently obvious that "32" and 32 are > equivalent, so > don't make developers worry about the distinction because to them there > isn't one. This is an entirely reasonable position. > > 2) PHP would benefit hugely from static analysis tools and compile-time > type-based optimizations, but those are only possible with code that is > strongly typed. Currently such tools do not really exist, but with > compile- > time-knowlable information could be written and even incorporated into > future versions of PHP without API breaks. (I think Anthony demonstrated > earlier examples of function calls no longer being slow, for instance, if > the > type juggling could be removed at compile > time.) This is an entirely reasonable position. Larry, There's actually very little difference between coercive type hinting and strict type hinting in terms of performance. If you read what both Dmitry and Anthony said, it should be clear that the vast majority of gains can be had even without any sort of type hinting at all - and as Stas pointed out, JavaScript has some mind blowing JIT optimizations without any explicit type info at all. Moreover, I think it's easy to lose the forest from the trees here, by focusing on a very narrow piece of code - without looking at the bigger picture. Ultimately, if you have a piece of data that you want to pass from a caller to a callee, it could be under one of three labels: 1. A piece of data the callee can use as-is. 2. A piece of data the callee can use after conversion (be it explicit or implicit). 3. A piece of data the callee cannot/shouldn't use. When comparing strict and coercive type hints, there's no difference between them in terms of #1; There's a subtle difference with #3 - but only in the error situation. In other words, for coercive type hints, it would just take a bit more time before they fail, because they have to conduct a few more checks. However, that's an error situation anyway, which is either already going to bail out, or go through error handling code - which would be very slow anyway. So focusing on #2, in a practical real world situation - the difference is actually a lot more subtle than people might think if they only zoom into on the area around parameter passing. The bigger picture is, what would the code author - the one making the call - want to do, semantically? In other words, if you have "32" coming from a database or whatnot, are you likely to want an API that accepts an int to be able to use that? I think the answer is almost always yes. So practically, what will happen with strict typing is that you'd explicitly cast it to int, while with coercive typing - you'd rely on the language to do it for you. Arguably, very little difference between the two in terms of performance. Note that it's possible people will be able to come up with various edge cases where strict typing might somehow alert you to a situation that may push you to change your code in a way it might end up being slightly faster. But those will be edge cases and should be taken in the context - in the vast majority of code patterns, there's zero difference between the two approaches in terms of performance. In terms of functionality, however, there's actually a substantial difference between the two - explicit casting is a lot more aggressive than the coercion rules we're thinking about for coercive type hints. It'll happily and silently coerce "Apple" into 0, "100 dogs" into 100, and 3.1415 into 3. Now, diving back to future potential AOT/JIT, it's simply not true that there's any gain at all from strict typing - or at least, neither Dmitry (who wrote a full JIT compiler for PHP that runs Mandelbrot as fast as gcc does) nor me were able to understand them. Anthony spoke about being able to completely eliminate the zval container and all associated checks, so that in certain situations you'd be able to map a PHP integer all the way down to a C (or asm) integer. That can certainly be done, but it has nothing to do with strict vs. coercive type hints. Here's why: 1. At this point I think it's clear to everyone that inside the called function, there's zero difference between strict and coercive typing (or even th
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message- > From: Lester Caine [mailto:les...@lsces.co.uk] > Sent: Thursday, February 19, 2015 12:24 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Reviving scalar type hints > > On 19/02/15 09:13, Zeev Suraski wrote: > > Obviously, I think 'weak' campers have a lot to gain too - by making > > sensible conversions work fine as expected, without having to resort > > to explicit casts. > > And everyone stands to gain from having just one mode, instead of two. > > The coercive typing approach would require each camp to give up a bit > > of their 'ideology', but it also gives both schools of thought *most* > > of what they want, including the key tenets for each camp (rejecting > > non-sensible conversions - always, allowing sensible ones - always). > > I believe that's what makes it a good compromise, a better one than > > the currently proposed RFC. > > Now that all made sense! > > My only grey area is 'allowing sensible ones' where the size is an > integral part > of what is 'sensible' ... the one where conventional strict typing uses a > type > of the right size? I think the guiding principal for these conversions should be no data loss. This may mean we have different limits on different architectures, depending on whether they're 32-bit or 64-bit. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 19, 2015 3:24 PM > To: franc...@php.net > Cc: Lester Caine; internals@lists.php.net > Subject: [PHP-DEV] Using Other Channels (was Scalar Type Declarations > v0.5) > > Let me quote something that was said: > > "Ze'ev and François have not-so-politely asked [Sara] to not put 0.4 > forward > since they have something they believe they have consensus on." Anthony, Please stop this. I have been in touch with Sara, yes, but it was absolutely and 100% polite, which I'm sure she'll confirm if you ask her. I can't speak for François as I wasn't a part of whatever correspondence they had between them. And no, quoting someone else instead of you making that statement and doesn't make it any better. > So while it may not have been "abandoned", it was sandbagged (sabotaged, > strong-armed, etc). I used abandoned as a light term to not point out to > list > what strong-arming happened behind the scenes. > But since you apparently don't want "other channels used"... > > I can't stress how deplorable that act is. How harmful to the community it > is > to ask in private for a contributor to stop what they are doing because > someone else "has a better idea". Strong-arming, sabotaging... Absolute nonsense, and offending nonsense at that. I, for one, didn't ask her to stop what she was doing. I try to get her opinion of an alternative which I - and many others - believe is better. I'll let her decide whether she wants to disclose her reply, but I can quote her public tweet, which I'm sure you've seen: "@ircmaxell @andrerom @trevorsuarez @zeevs @rasmus ftr, I'm deferring to a couple of other proposals on the table. Doesn't need to be mine." There's absolutely nothing deplorable about talking to Sara off list. As I told her in my email, I wanted to first gauge her opinion about that proposal and see if she was willing to support it. I did not push her to abandon v0.4. To be clear, the proposal you're pushing as v0.5 is very different from what she had in mind for v0.4, based on the initial discussions on internals. She was trying to listen in to issues and come up with substantial changes to the v0.3 RFC to radically increase the consensus around it. v0.5, on the other hand, is, for the most part, v0.3 with opinionated, discussionless explanations of why it's absolutely fine to keep as-is. > We had a proposal that *had* consensus > (66%). It was withdrawn. 66% is not consensus. It's a form of special majority but by any stretch absolutely not consensus in any definition of the word. I'm not going to refer to your guesstimates you have about your ability to reach consensus with slight modifications to the proposal, but I can say that I know there are at least a few people that voted yes, and in light of the new proposal that's forming up would now vote no, preferring that new option. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 19, 2015 4:04 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations > v0.5) > > Zeev, > > That was a quote directly from Sara in a public chat room. It wasn't > "someone else". > > So it seems like there was a failure in communication if you felt that it > was > 100% polite, and she described it as "not-so-politely". Ouch. I'm really not sure why she felt that way. I'll follow up with her to try and understand. > Then that's great! But let's find that out by voting rather than guessing, > and > rather than politicking. Let's let two competing proposals go head to > head. I'd rather find out by first discussing the alternative, rather than just moving ahead to a revote - especially a revote that was placed on a shortened timeline - given the importance of this RFC. But as you clearly disagree, it's your call to make and I respect that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
> -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Thursday, February 19, 2015 4:09 PM > To: Zeev Suraski > Cc: Anthony Ferrara; PHP internals > Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations > v0.5) > > We have seen off list discussions or pressures many times in the pasts. I > have > (other too but I can only talk for myself) been said an insane amount of > times > to stop private discussions, for anything related to php core. There is no > exception to this rule. I repeat: > There is NO exception to this rule. I disagree. Completely. I think 1:1 or group discussions are completely legitimate, and they're not only legitimate - they can be very productive. There's a huge gap between making decisions in closed groups, or doing 'arm bending' - and private discussions, which I repeat, are completely legitimate. Private discussions happen all the time, in countless mediums. Conferences, emails, IRC (public in theory, private in practice), Twitter DMs and more. There's absolutely nothing wrong with discussing an idea directly with one or more people before bugging thousands of people with it. They'd all be better served if the idea presented to them already had a slightly more than just one person standing behind it (which is an inherent side effect of barring private discussions as you suggest), and had some of the initial issues weeded out. Now, if such ideas are presented as a final dictation with no opportunity to discuss them - that's is in fact problematic, although ultimately, there's always the bar of the vote. Regardless, this isn't the case here. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 19, 2015 4:24 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations > v0.5) > > Zeev, > > This topic has been discussed to death in circles over the past several > years. > You're involved now. Awesome. Show me why your proposal is better rather > than trying to just tell me to stop or pause. Show the result of the > discussion. I already said I respect your decision, even if I disagree with it. Holding absolutely no grudge. The key tenets of the proposal that's being worked on have already been shared on internals. Without putting words in your mouth, based on the feedback you've provided over the last few days I don't have high hopes that you personally would find it better, but I'm hoping many others would. The formal RFC takes a bit more time to phrase, but I hope we'll be able to finish the first version today or tomorrow. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
> -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Thursday, February 19, 2015 4:52 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations > v0.5) > > On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski wrote: > To discuss at an idea or concept at events and co? Indeed. We all do that. > The difference is how to move it to a group discussions and grab other > people thoughts to actually get it done, with consensus. The latter part > is > totally absent using your process. What exactly are we discussing here? My email to Sara yesterday? Or your gripes with how PHPNG was handled? I have no intention to discuss the latter, as it's been beaten to death ages ago; And everything you're bringing up appears to be completely disconnected to the former, which was supposedly the trigger to your email. If it's just an excuse to reopen the PHPNG discussion, I'm not going to play along with it. Focusing on my email to Sara (and several others), there is NOTHING, nothing wrong with a bit of private communications trying to gauge support, opposition, gaps and sort out differences before going for a public discussion. Personally I think it's ridiculous to suggest otherwise, and it's completely equivalent to the stuff you stated 'we all do'. But obviously you're entitled to a different opinion, including one that thinks my position is ridiculous. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On 19 בפבר׳ 2015, at 22:08, Anthony Ferrara wrote: > > Zeev, > > Based on Sara's clarification in this thread, I owe you a formal > apology. I interpreted something she said incorrectly, which was then > compounded by messages in private and on-list this morning. I then > attributed both of you qualities and motives that have been proven > false. > > For this, I am sorry for any implication or direct acquisition that I > made against you. Apology accepted! No worries. > I do believe that the best way forward is parallel proposals, as I > believe that we have different goals. So I look forward to seeing > yours, and will continue forward with mine. Hopefully this differing > of opinion can be rectified before too long. Me too! Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Nightmares on type hints, annotations, and aop...
Bishop,
Pardon me for saying so, but I don't think you're on to a huge scoop here.
Scalar type hints - of all the kinds we've been talking about here, be them
strict, weak or coercive - can be easily emulated with a couple of lines of
code, we all know that. It's been known for years that strict hints are
is_*() else error equivalent, that weak hints are (mostly) just casts, etc.
Saying the class type hints can be emulated with is_a() calls wouldn't shock
anybody either.
However, the conclusion you seem to draw from that, few language designers
would agree with. Adding first-class, reflectable, analyzable syntax - is
worlds apart from the situation today - regardless of what type of scalar
hinting we talk about. Once we introduce language-level syntax for this
pattern, usage will *explode* compared to what it is today. Explode, not
increase. Tools would be updated to support (and take advantage) of this
new data - in a way they can't practically do with userland 'emulation' of
this behavior. Best practices will be updated. Doc formats will be
changed. Etc etc.
Last, note that you only focused on userland functions. Things are a bit
different with internal functions. The different proposals on the table all
propose to change - in one way or another - the way internal functions
behave. This is much less intuitive to emulate using userland code, for
obvious reasons.
So no, I don't think we're making a bigger deal out of it than it is.
Scalar type hints are a huge deal, and the fact you can emulate them in
userland code today doesn't change that in any way.
Thanks,
Zeev
> -Original Message-
> From: bishop.bett...@gmail.com [mailto:bishop.bett...@gmail.com] On
> Behalf Of Bishop Bettini
> Sent: Wednesday, February 18, 2015 2:18 PM
> To: PHP internals
> Subject: [PHP-DEV] Nightmares on type hints, annotations, and aop...
>
> After a spate of literal coding nightmares, I woke needing to commit these
> thoughts to the list. These may have been raised before, I can't
> remember,
> these debate has been raging for so long.
>
>
> THING 1: Hints are just is_* wrappers
>
> function f(scalar $s, int $i) { }
>
> effectively is sugar for:
>
> function f($s, $i) {
> if (! is_scalar($s)) throw new \InvalidArgumentException();
> if (! is_int($i)) throw new \InvalidArgumentException(); }
>
>
> THING 2: Hints are truthy callables
>
> function my_mixed($m) {
> return (null === $m || is_string($m)); } function f(is_scalar $s,
> is_int $i,
> my_mixed $m) {};
>
>
> THING 3: Pre- and post- blocks to define contracts, establish formal join
> points, with or without hints from above
>
> function f($s, $i, $m)
> before {
> if (! is_scalar($s)) throw new \InvalidArgumentException; }, inside {
> $fp = fopen($s, 'r');
> return [ $i, $m ];
> },
> after ($retval) {
> assert(is_array($retval) && 2 === count($retval)); }, finally
> ($retval) {
> fclose($fp);
> if ($retval instanceof \Exception) {
> // I got here by an unhandled exception
> }
> }
>
> weave('before', 'f', function ($s, $i, $m) {
> syslog(LOG_DEBUG, __POINTCUT__); // is 'f'
> }
>
>
> I had to get these off my chest. Forgive me their implementation
> ignorance.
> I am yet tired and uncaffeinated. To the void I commit their bodies...
>
> bishop
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
> On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara wrote: > > verification and static analysis aren't enough? > Anthony, While IMHO they're not enough to warrant substantial deviation from PHP's behavior, this is a subjective question that others might answer differently. But there's also an objective issue. There's a serious question mark whether the type of hint - strict, coercive of otherwise can have any sort of implications on one's ability to conduct static analysis, JIT or AOT (I'm bringing those up again since they're closely related in terms of what you can or cannot infer). Now, I'll contend that even though I don't think we are, perhaps we're missing something. But at the very least it should be clear to the list there's serious doubt on whether there's any extra value there even if they do seem static analysis critical. If there is, it's likely to be very, very limited in scope. > That's not saying you should want to use statically typed for > everything. And nor would I support PHP moving to pure statically > typed (which is why the proposal I'm backing doesn't). We're on the same page here. But the kinds of static analysis benefits you seem to believe we can get from strict type hints would require that - strong typing, variable declarations, perhaps changes to casting rules - not just around that narrow interface between callers and callees. Thankfully that's not on the table. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, February 21, 2015 1:36 AM > To: Larry Garfield > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Reviving scalar type hints > > Larry, > > On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield > wrote: > > On 02/20/2015 06:28 PM, Anthony Ferrara wrote: > >> > >> Considering I'm not targetting 7 (I've updated the RFC to hint this), > >> we can choose what to do later depending on the exceptions result > >> (whether to bypass execution in strict mode only, or for all calls). > >> Thanks for the insight Anthony > > > > > > That makes me very sad, as whether the strict option is there or not > > I'd > > *really* love to see scalar hints in PHP 7 to complement return type > > hinting. > > Timing just won't work while being fair with alternative proposals. > I've said since I re-opened the proposal that I'm comfortable with it not > targeting 7.0... > > Unless we're willing to push feature freeze by 2-3 weeks for it, it just > doesn't > make sense to target 7 with people working on an alternate proposal (since > by definition they couldn't target 7). Anthony, Following Adam's analysis of the timeline, taking the more 'strict' (no pun intended!) interpretation of the timeline RFC, we still have until tomorrow to start the discussion and still target it for 7.0, no? Given the importance of this topic, I'd go for the more lax interpretation that allows for votes to begin by March 15, giving us all a bit more time to discuss. I don't think any of us, on any camp, wants to wait for 2016 for this. Thoughts? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, February 21, 2015 5:23 PM > To: Zeev Suraski > Cc: Larry Garfield; internals@lists.php.net > Subject: Re: [PHP-DEV] Reviving scalar type hints > > I'm fine with that. My interpretation was that the feature freeze would > happen on March 15 (that afterwards no new RFCs would be accepted). > > I made the decision to target 7.next/8 based on the assumption that the > competing RFC would not be able to fairly target 7.0. If you are saying > that's > not the issue, then I'll happily re-target this RFC for > 7.0 again. > > I just didn't want to be seen as (or actually do) pushing based on a > timing > advantage that your proposal couldn't possibly meet. > > So if you're fine with it (which it seems you are), I'll re-target the RFC > now. I am fine with it, as long as we all agree for the lax interpretation of the March 15 deadline (vote must start by then). Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Coercive Scalar Type Hints RFC
All, I’ve been working with François and several other people from internals@ and the PHP community to create a single-mode Scalar Type Hints proposal. I think it’s the RFC is a bit premature and could benefit from a bit more time, but given the time pressure, as well as the fact that a not fully compatible subset of that RFC was published and has people already discussing it, it made the most sense to publish it sooner rather than later. The RFC is available here: wiki.php.net/rfc/coercive_sth Comments welcome! Zeev
[PHP-DEV] [RFC] Coercive Scalar Type Hints
[Resending with the correct Subject line :)] --- All, I’ve been working with François and several other people from internals@ and the PHP community to create a single-mode Scalar Type Hints proposal. I think it’s the RFC is a bit premature and could benefit from a bit more time, but given the time pressure, as well as the fact that a not fully compatible subset of that RFC was published and has people already discussing it, it made the most sense to publish it sooner rather than later. The RFC is available here: wiki.php.net/rfc/coercive_sth Comments welcome! Zeev
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, February 21, 2015 8:12 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > First off, thanks for putting forward a proposal. I look forward to a > patch > that can be experimented with. > > There are a few concerns that I have about the proposal however: > > > Proponents of Strict STH cite numerous advantages, primarily around code > safety/security. In their view, the conversion rules proposed by Dynamic > STH > can easily allow ‘garbage’ input to be silently converted into arguments > that > the callee will accept – but that may, in many cases, hide > difficult-to-find > bugs or otherwise result in unexpected behavior. > > I think that's partially mis-stating the concern. I don't think it is, based It's less about "garbage input" > and more about unpredictable behavior. You can't look at code and know > that it will not produce an error with dynamic typing. That's one of the > big > advantages of strict typing that many people want. In reality the reasons > are > complex, varied and important to each person. > > > Proponents of Dynamic STH bring up consistency with the rest of the > language, including some fundamental type-juggling aspects that have been > key tenets of PHP since its inception. Strict STH, in their view, is > inconsistent > with these tenets. > > Dynamic STH is apparently consistency with the rest of the language's > treatment of scalar types. It's inconsistent with the rest of the > languages > treatment of parameters. > > However there's an important point to make here: a lot of best practice > has > been pushing against the way PHP treats scalar types in certain cases. > Specifically around == vs === and using strict comparison mode in > in_array, > etc. > > So while it appears consistent with the rest of PHP, it only does so if > you > ignore a large part of both the language and the way it's commonly used. > > In reality, the only thing PHP's type system is consistent at is being > inconsistent. > > > > In the "Changes To Internal Functions" section, I think all three types > are > significantly flawed: > > 1. "Just Do It" - This is problematic because a very large chunk of code > that > worked in 5.x will all of a sudden not work in 7.0. This will likely > create a > python 2/3 issue, as it would require a LOT of code to be changed to make > it > compatible. > > 2. "Emit E_DEPRECATED" - This is problematic because raising errors (even > if > suppressed) is not cheap. And the potential for raising one for a > non-trivial > percentage of every native function call has the potential to have a > MASSIVE > performance impact for code designed for 5.x. Without a patch to test, it > can't really be codified, but it would be a shame to lose the performance > gains made with 7 because we're triggering 100's, 1000's or 1's of > errors > in a single application run... > > 3. "Just Do It but give users an option to not" - This has the problems > that > E_DEPRECATED has, but it also gets us back to having fundamental code > behavior controlled by an INI setting, which for a very long time this > community has generally seen as a bad thing (especially for portability > and > code re-use). > > > > Moving along, > > > Further, the two sets can cause the same functions to behave > > differently depending on where they're being called > > I think that's misleading. The functions will always behave the same. > The difference is how you get data into the function. The behavior > difference > is in your code, not the end function. > > > For example, a “32” (string) value coming back from an integer column in > > a > database table, would not be accepted as valid input for a function > expecting > an integer. > > There's an important point to consider here. You're relying on information > outside of the program to determine program correctness. > So to say "coming back from an integer column" requires concrete > knowledge and information that you can't possibly have in the program. > What happens when some DBA changes the column type to a string type. > The data will still work for a while, but then suddenly break without > warning > when a non-integer value comes in. Because the value-information comes > from outside. > > With strict mode, you'd have to embed a cast (smart or explicit) to > convert
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
Sorry for the previous prematurely sent email, looks like I found a new keyboard shortcut :) > -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, February 21, 2015 8:12 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > First off, thanks for putting forward a proposal. I look forward to a > patch > that can be experimented with. > > There are a few concerns that I have about the proposal however: > > > Proponents of Strict STH cite numerous advantages, primarily around code > safety/security. In their view, the conversion rules proposed by Dynamic > STH > can easily allow ‘garbage’ input to be silently converted into arguments > that > the callee will accept – but that may, in many cases, hide > difficult-to-find > bugs or otherwise result in unexpected behavior. > > I think that's partially mis-stating the concern. I don't think it's mis-stating the key concern. At least not based on what I've heard from most people here over the last few months. > It's less about "garbage input" > and more about unpredictable behavior. You can't look at code and know > that it will not produce an error with dynamic typing. That's one of the > big > advantages of strict typing that many people want. In reality the reasons > are > complex, varied and important to each person. Your ability to look at code and know whether or not it will produce errors is very similar in both strict and coercive typing. But that goes back to what we already decided to agree to disagree on - whether or not strict type give you any tangible extra data when you look at code - aka Static Analysis. Note that Strict Typing would produce all the errors of coercive typing and then some. So knowing whether code will produce errors is arguably more difficult in strict typing, although I think that at the end of the day, it's pretty much equivalent. Again, I did see Static Analysis being brought up by just a handful of people, perhaps not even that. For most people, it was the silent acceptance of input that's likely to be invalid. > > Proponents of Dynamic STH bring up consistency with the rest of the > language, including some fundamental type-juggling aspects that have been > key tenets of PHP since its inception. Strict STH, in their view, is > inconsistent > with these tenets. > > Dynamic STH is apparently consistency with the rest of the language's > treatment of scalar types. It's inconsistent with the rest of the > languages > treatment of parameters. Not in the way Andrea proposed it, IIRC. She opted to go for consistency with internal functions. Either way, at the risk of being shot for talking about spiritual things, Dynamic STH is consistent with the dynamic spirit of PHP, even if there are some discrepancies between its rule-set and the implicit typing rules that govern expressions. Note that in this RFC I'm actually suggesting a possible way forward that will align *all* aspects of PHP, including implicit casting - and have them all governed by a single set of rules. > However there's an important point to make here: a lot of best practice > has > been pushing against the way PHP treats scalar types in certain cases. > Specifically around == vs === and using strict comparison mode in > in_array, > etc. I think you're correct on comparisons, but not so much on the rest. Dynamic use of scalars in expressions is still exceptionally common in PHP code. Even with comparisons, == is still very common - and you'd use == vs. === depending on what you need. > So while it appears consistent with the rest of PHP, it only does so if > you > ignore a large part of both the language and the way it's commonly used. Let's agree to disagree. That's one thing we can always agree on! :) > In reality, the only thing PHP's type system is consistent at is being > inconsistent. I'd have to partially agree with you here; But if you read the RFC through including its future recommendations, you'd see it's perhaps the first attempt in 20 years to fix that. Instead of doing that through the introduction of a 3rd (albeit simplistic rule-set that only pays attention to zval.type) - a creation of a single set of rules that will be consistent across the whole language, beginning with userland and internal functions. > In the "Changes To Internal Functions" section, I think all three types > are > significantly flawed: > > 1. "Just Do It" - This is problematic because a very large chunk of code > that > worked in 5.x will all of a sudden not work in 7.0. This will likely > create a > python 2/3 issue, as it wou
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Pádraic Brady [mailto:padraic.br...@gmail.com] > Sent: Saturday, February 21, 2015 9:56 PM > To: Zeev Suraski > Cc: Anthony Ferrara; PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > > The sentence stresses garbage in too much to read as accurate. To clarify, > there is a) garbage in due to weak coercion and b) a function being called > with a string when the typehint says int. Both are separate concerns > around > error detection. Stricter coercion can enable only one of these two, for > example. That's better than neither, of course! The coercion rules were > stricter than I expected based on previous emails. Stressing one too much > might suggest to a reader that the second concern does not exist. As I told Anthony, based on what I saw on the list, the former appeared to be a much more widely-held concern than the latter. > Other pedantic comment: "numerous" is probably too strong a word there. > The advantages may vary by person, but usually fit within basic > five-finger > math. It would be more important to enumerate them rather than selecting > one as primary. Thanks, changed to 'several'. Double thanks, as I always thought 'Numerous' was more or less equivalent to 'Several', and you made me look it up :) > On the RFC rules themselves, a few comments: > > 1. Happy to see leading/trailing spaces excluded. Happy to see you happy! > 2. Rules don't make mention of leading zeroes, e.g. 0003 3. "1E07" might > be > construed as overly generous assuming we are excluding stringy integers > like > hex, oct and binary 4. I'm assuming the stringy ints are rejected? It's up for discussion. I personally don't have very strong feelings on how we deal with these cases, as the main thing I care about is for the common cases to work. That said, if it was entirely up to me, I'd accept "0003" but not "1E07" - as the latter is considered floating point: $x = "1e7"; print gettype($x+0); // would print double But if rejecting leading zeros is what's needed to get a lot more people to support it, I can live with that. > 5. Is ".32" coerced to float or only "0.32"? Merely for clarification. With the same disclaimer as the one for the previous answer, I'd go with accepting ".32" in the same way is_numeric() accepts it. > 7. In string to float, only capital E or also small e? I think both, same is_numeric() rationale - same disclaimer. > 8. I'll never stop call them "stringy" ints. I can live with that :) Thanks for the feedback! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, February 21, 2015 10:08 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > I won't nit-pick every point, but there are a few I think need to be > clarified. > > >> > Proponents of Dynamic STH bring up consistency with the rest of the > >> language, including some fundamental type-juggling aspects that have > >> been key tenets of PHP since its inception. Strict STH, in their > >> view, is inconsistent with these tenets. > >> > >> Dynamic STH is apparently consistency with the rest of the language's > >> treatment of scalar types. It's inconsistent with the rest of the > >> languages treatment of parameters. > > > > Not in the way Andrea proposed it, IIRC. She opted to go for > > consistency with internal functions. Either way, at the risk of being > > shot for talking about spiritual things, Dynamic STH is consistent > > with the dynamic spirit of PHP, even if there are some discrepancies > > between its rule-set and the implicit typing rules that govern > > expressions. Note that in this RFC I'm actually suggesting a possible > > way forward that will align *all* aspects of PHP, including implicit > > casting - and have them all governed by a single set of rules. > > The point I was making up to there is that we currently have 2 type > systems: user-land object and ZPP-scalar. So in any given function you > have 2 > type systems interacting. The current ZPP scalar type is dynamic, and > user- > land object static. Objects and scalars are fundamentally different, definitely in PHP.. There's no standard way to convert an instance of a certain class to an instance of another class, at least not in PHP. There is, however, a standard way of converting different types of scalars to one another, and this behavior is extremely ubiquitous in PHP. That is the reason that when class type hints were introduced, it was at the *condition* that we'll not have strict scalar type hints, because scalars were (and still are) so fundamentally different than objects and in many cases can losslessly change type in a well-defined manner. Perhaps if we had the coercive STH idea back then we could have saved us all a lost decade without scalar type hints. I'll say it again - scalars and objects (and for that matter any non-scalar type including arrays and resources) - are inherently different, and striving for consistency between them should not be a goal IMHO. > Let's agree to disagree that an ini setting will be better than a per-file > setting. We can agree to disagree on that, but not on the fact that the Coercive STH RFC provides a roadmap, at the end of which we'd have a single mode, consistently behaving(*) and more secure-for-everyone language - and one without that INI entry (it's a temporary measure that will be removed). The Dual Mode RFC, on the other hand, we're introducing two modes that we'll have to support for all eternity, with two potential 'camps' of developers forming up, and with no security benefits for anybody who doesn't choose to flip on the strict switch. (*) With the exception of Scalar/non-Scalar consistency, which again, I find hard to accept as a valid goal. > >> > Further, the two sets can cause the same functions to behave > >> > differently depending on where they're being called > >> > >> I think that's misleading. The functions will always behave the same. > >> The difference is how you get data into the function. The behavior > >> difference is in your code, not the end function. > > > > I'll be happy to get a suggestion from you on how to reword that. > > Ultimately, from the layman user's point of view, she'd be calling > > foo() from one place and have it accept her arguments, and foo() from > > another place and have it reject the very same arguments. > > Let me think on it and I will come up with something. Thanks. > I agree we should have users avoid explicit casts. That's why the > dual-mode > proposal exists. If users don't want to control their types, they should > use the > default mode. And everything works fine. This ignores the reasonable guesstimate - raised by several people here - that many will flip Strict mode on because they'd think it makes them inherently safer, faster, or just a good thing to do. Everything I've learned about PHP in the last couple of decades tells me there are going to be plenty of those. Those are the same people who would quickly then add explicit cas
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
Márcio, I hope to be able to work on an actual implementation and have something by the end of the upcoming week, allowing us all to experiment. Other than tweaking the conversion table, which based on the feedbacks I * *believe** can be done in a way everyone can live with – I agree that the biggest open question is how we deal with internal functions. Also note that the, the 2nd proposed option in the RFC (“Emit E_DEPRECATED in 7.0, move to E_RECOVERABLE_ERROR in v7.1 or v8.0”) – of marking newly-rejected-conversions as E_DEPRECATED is not considered as a BC break IMHO. The code would still work, and the likelihood that something bad was legitimately found is pretty high. Given the compressed timeline, I wanted to gauge the general response as soon as possible, and also start the RFC discussion process as soon as possible, which meant we couldn’t include the implementation to go along with it. Two more things regarding the competing RFC – it’s still alive, and being promoted for PHP 7.0; And while it doesn’t create a huge BC break, it allows developers to selectively create localized BC breaks, on a per file basis. Thanks for the feedback! Zeev Thanks for your effort and for proposing the RFC so quick. But indeed, as you said, this is really premature. According to my interpretation the RFC proposes a potentially huge bc break on internal functions usage while the competing (recently withdraw) RFC was BC compatible regarding this. Having this proposal without a working patch, so we can try the real impact it could have before form opinions, frankly, doesn't sound like a good idea. I know it's still a draft but, considering the RFC is aimed to v7.0, I hope to see a working implementation before the feature freeze just like what was exemplary made with the other previous withdraw proposals. Thanks, Márcio
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
Benjamin, There’s a fundamental difference between the two RFCs that goes beyond whether using a global INI setting and the other per-file setting. The fundamental difference is that the endgame of the Dual Mode RFC is having two modes – and whatever syntax we’ll add, will be with us forever; and in the Coercive STH RFC – the endgame is a single mode with no INI entries, and opening the door to changing the rest of PHP to be consistent with the same rule-set as well (implicit casts). The challenge with the Coercive STH RFC is figuring out the best transition strategy, but the endgame is superior IMHO. Regarding the proposed migration options, yes, if we pick option #2 or #3 – we’d be introducing an INI entry governing runtime behavior is something nobody here wants, myself included – but given that it’ll be time limited (perhaps for as short as 1 or 2 years) – perhaps that’s something we can live with. Additional options we could entertain are: 4. Not applying the rules for internal functions at all. Personally I’m not very fond of this option. 5. Go for just E_DEPRECATED in 7.0. Change E_DEPRECATED to E_RECOVERABLE_ERROR in 7.1/7.2/8.0 (TBD). 6. Same as #5, but also provide a mechanism similar to declare() as the temporary measure for strict campers to explicitly ask for E_RECOVERABLE_ERROR’s to be triggered. They will no longer be necessary when we change E_DEPRECATED to E_RECOVERABLE_ERROR in 7.1/7.2/8.0. Thoughts? Zeev I was really looking forward to the RFC. However the dependence on an INI setting and the question of massive internal BC break are a bit too much I think. They are necessary as you explain to allow internal functions/ZPP to have the same conversion rules as userland functions. This INI setting is quite similar to introducing two modes as well, but on the server configuration level instead in a much more fine granular way in scalar type hints v0.5. I see much more compatibility problems for third party libraries here. Now if I had to decide between having two modes on a granular file level or an INI setting (option 2/3) or massive BC breaks (option 1) to get scalar type hints in PHP, then two modes with declare() doens't look, because I can pick the mode I want, and no-one can force it on me. Zeev
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Sunday, February 22, 2015 12:25 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > > "with two potential 'camps' of developers forming up" > > Have you looked at the community lately? That's been happening for a > decade. One camp likes to engineering everything out using classes and > libraries. The other keeps using PHP procedurally and ignoring changing > "best > practices" (and I do mean the quotes). Does that make one better than the > other? NO. I don't think these two camps map to the strict and dynamic camps, definitely not for the userbase at large. Which means that whatever camps we have today, we'd have more - one extra point of division. > And that's PHP's strength. It gives both sides the power to keep doing > what > they want to be doing without having to give up or be burdened by the > other > side. I explained both in the RFC and here why I don't think providing two modes for doing something quite similar are good. We can agree to disagree :) > Sure, some people will do that. Just like people still use single quotes > because > they are faster. Not quite IMHO - that example actually requires some relatively advanced knowledge. Strict, with the amount of noise that Scalar Type Hints are bound to get (and are already getting) - is bound to have a lot more exposure than single quotes being faster ever had. And it's therefore very likely it'll be used by people who shouldn't really be using it. Let's leave the Static Analysis part aside, and agree to disagree as we already did numerous times but failed to implement. > > Two more things regarding the competing RFC – it’s still alive, and > > being promoted for PHP 7.0; And while it doesn’t create a huge BC > > break, it allows developers to selectively create localized BC breaks, > > on a per file basis. > > No, it does not. A BC break is something where existing code works, and > you > do nothing more than upgrade and have the new code not work anymore. > > With the other dual-mode RFC, if a user opts-in (enables strict mode), if > code > doesn't work that's not a BC break. That's a case of "you told us explicit > you > don't want this code to work if it's invalid, and guess what, it's > invalid". That's splitting hairs IMHO. The bottom line is that many people will undergo the same process Rasmus did as he experimented, flipping the switch on because it's a best practice, and start having to fix their code to work. But we can also agree on what we always agree here too :) Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive Scalar Type Hints RFC
On 22 בפבר׳ 2015, at 02:07, François Laupretre wrote: >> De : Lester Caine [mailto:les...@lsces.co.uk] >> >> Fixed length fields may well be a data source so having to strip them >> before using them just seems a backward step. The basic C library simply >> strips the white space so are we looking at using an alternative? > > I guess you got it wrong : we'll ignore leading and trailing blanks, as well > as leading 0s. We say we restrict because, where we accepted *every* trailing > chars, we now only accept blanks. So fixed length fields will work as before. Actually the Coercive STH RFC currently takes the position that leading or trailing spaces will not be accepted. In general, the idea is to support the conversions which are likely to be right and safe in the vast majority of cases, and if there's any doubt - reject it. It's of course up for discussion, but it's that concept that I believe can bridge the gap between proponents of strict and proponents of dynamic typing. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
From: Etienne Kneuss [mailto:col...@php.net] Sent: Sunday, February 22, 2015 3:00 PM To: Anthony Ferrara; Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > The question is rather: at what weight should we take (potential/future) > external tools into account when developping language features? Agreed! My answer - "Static Analyzers need to be designed for Languages, rather than Languages being designed for Static Analyzers". Will send additional thoughts on Static Analysis on a separate, off-list email to put this argument to rest as both Anthony and agreed to. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message-
> From: Jefferson Gonzalez [mailto:jgm...@gmail.com]
> Sent: Sunday, February 22, 2015 4:25 PM
> To: Etienne Kneuss; Anthony Ferrara; Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
Jefferson,
Please note that Anthony, the lead of the Dual Mode RFC, said this earlier
on this thread, referring to the claim that Strict STH can improve JIT/AOT
compilation:
"A statement which I said on the side, and I said should not impact RFC or
voting in any way. And is in no part in my RFC at all."
Please also see:
marc.info/?l=php-internals&m=142439750614527&w=2
So while Anthony and I don't agree on whether there are performance gains
to be had from Strict STH, both of us agree that it's not at a level that
should influence our decision regarding the RFCs on the table.
I wholeheartedly agree with that stance, which is why I also listed the
apparently extremely widespread misconception (IMHO) that Strict STH can
meaningfully help JIT/AOT in my RFC.
Despite that, as your email suggests, there are still (presumably a lot)
of people out there that assume that there are, in fact, substantial gains
to be had from JIT/AOT if we introduce Strict STH. I'm going to take
another stab at explaining why that's not the case.
> A JIT or AOT machine code generator IMHO will never have a decent use of
> system resources without some sort of strong/strict typed rules,
somebody
> explain if thats not the case.
It kind of is and kind of isn't.
There's consensus, I think, that if PHP was completely strongly typed -
i.e., all variables need to be declared and typed ahead of time, cannot
change types, etc. - we'd clearly be able to create a lot of optimizations
in AOT that we can't do today. That the part that 'is the case'. But
nobody is suggesting that we do that. The discussion on the table is
very, very narrow:
-- Can the code generated for a strict type hint can somehow be optimized
significantly better than the code generated for a dynamic/coercive type
hint.
And here, I (as well as Dmitry, who actually wrote a JIT compiler for PHP)
claim that it isn't the case. To be fair, there's no consensus on this
point.
Let me attempt, again, to explain why we don't believe there are any gains
associated with Strict STH, be them with the regular engine, JIT or AOT.
Consider the following code snippet:
function strict_foo($x)
{
if (!is_int($x)) {
trigger_error();
}
.inner_code.
}
function very_lax_foo($x)
{
$x = (int) $x;
.inner_code.
}
function test_strict()
{
.outer_code.
strict_foo($x);
}
function test_lax()
{
.outer_code.
very_lax_foo($x);
}
test_strict();
test_lax();
strict_foo() implements a pretty much identical check to the one that a
Strict integer STH would perform.
very_lax_foo() implements an explicit type conversion to int, that can
pretty much never fail - which is significantly more lax than what is
proposed for weak types in the Dual Mode RFC, and even more so compared to
the Coercive STH RFC.
.inner_code. is identical between the two foo() functions, and
.outer_code. is identical between the two tester functions.
The claim that strict types can be more efficiently optimized than more
lax types, suggests it should be possible to optimize the code flow for
test_strict()/strict_foo() significantly better than for very_lax_foo()
using JIT/AOT.
Let's dive in. Beginning with the easy part, that's been mentioned
countless times - it's clear that it's just as easy (or hard) to optimize
the .inner_code. block in the two implementations of foo(). It can bank
on the exact same assumptions - $x would be an integer. So we can
optimize the two function bases to exactly the same level. For example,
if we're sure that $x inside the function never changes type - it can be
optimized down to a C-level long. That's oversimplifying things a bit,
but the important thing here is that it can be easily proven that the two
function bodies can be optimized to the exact same level, for better or
worse. The only difference between them is how they handle non-integer
inputs; The strict implementation errors out if it gets a non-integer
typed value, while the lax version happily accepts everything. But that's
a functionality difference, not a performance one (i.e., if you want the
value to be accepted in the strict case, you'd manually conduct the
conversion before the call is made, or sooner - resulting in roughly the
same behavior and performance).
Now the slightly trickier part - the .outer_code. block. What can we say
about the type of $x, without knowing what code is in there? Not a whole
lot. We know that if $x isn't going to be of type int at the end of this
block, test_strict() is going to fail, but that doesn't mean $x will truly
be an int. The fa
[PHP-DEV] RE: JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
[I hope I managed to get the threading right although I think it's more
than likely I didn't; apologies in advance if that's the case]
> -Original Message-
> From: Joe Watkins [mailto:pthre...@pthreads.org]
> Sent: Sunday, February 22, 2015 5:07 PM
> To: Jefferson Gonzalez
> Cc: Etienne Kneuss; Anthony Ferrara; Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> > 1. Does weak mode could provide the required rules to implement a JIT
> with a sane level of memory and CPU usage?
>
>
>
> There is no objective answer to the question while it has the clause
"with a
> sane level of ...".
>
>
> The assertion in the RFC that says there is no difference between strict
and
> weak types, in the context of a JIT/AOT compiler, is wrong.
Can we take a hint from youtu.be/9MV1ot9HkPg please? :)
> function add(int $l, int $r) {
> return $l + $r;
> }
>
> The first instruction in the interpreted code is not ZEND_ADD, first,
> parameters must be received from the stack.
>
> If that's a strict function, then un-stacking parameters is relatively
easy, if it's
> a dynamic function then you have to generate code that is considerably
> more complicated.
Can you explain how so, assuming you know the same about what's waiting on
the stack in both cases? If you know they're already ints, you can
optimize the function to take this assumption into account - identically -
in both the case of a strict or dynamic hint (and as a matter of fact,
even if there's no hint at all). If, however, you don't know what's
waiting on the stack - you would have to conduct checks in both cases.
Sure, the checks are different - but the difference between them is
behavioral, semantic - not performance related.
> This is an inescapable difference, of the the kind that definitely does
have a
> negative impact on implementation complexity, runtime, and
maintainability.
This inescapable difference somehow manages to escape a bunch of people
here, myself included...
> To me, it only makes sense to compile strict code AOT or JIT; If you
want
> dynamic behaviour, we have an extremely mature platform for that.
I'll have to disagree with that statement. I'm not yet sure what we can
achieve with JIT in real world PHP web apps, but I've seen enough to know
that with JIT, certain use cases which are impractical today due to
performance (mainly data crunching) suddenly become viable. And that's
with no STH at all, strict or otherwise. Our JIT POC runs bench.php 25
times faster than PHP 7, without a single byte changed in the source (no
typo, 25 times faster, not 25%). Unfortunately, most real world app code
doesn't look anything like what bench.php does - but it should illustrate
the point about the viability of JIT/AOT for dynamic platforms.
To take another example, JavaScript is extremely lax, are you suggesting
that it doesn't make sense to use JIT with JavaScript? JIT made JS
performance literally explode, without changing the language to be strict.
If what you can already discern from dynamic type inference (which is
quite a lot, as JS proves) isn't enough for you - what you need isn't some
specific kind of type hinting (strict or otherwise) - but more tools to
tell what the type is in situation where today you can't (or find it hard
to) infer it. Strictly typed variable declarations would be one such
thing, changing how our operators work to be more strict would be another
(for the record, I'm absolutely not suggesting we do that!). In short,
changing PHP to be a much more strongly typed language than it is today,
with or without Strict STH.
> > 2. ... With that said, if a JIT implementation is developed will the
story of
> the ZendOptimizer being a commercial solution will be repeated or would
> this JIT implementation would be part of the core?
>
> I think it's likely that Anthony and I, and Dmitry want different things
for a
> JIT/AOT engine. I think Anthony and I are preferring an engine that
requires
> minimal inference because type information is present (or implicit),
I don't see how that's possible, unless you add facilities such as the
ones I mentioned above. If that's the goal, I think it should be clearly
stated. Without that, you need the exact same type inference with strict
and weak types in order to develop useful JIT/AOT.
>while
> Dmitry probably favours the kind that can infer at runtime, the dynamic
kind,
> like Zend is today. They are a world apart, I think, I'll be happy to be
proven
> wrong about that.
The difference is really not about what kind of JIT implementation anyone
prefers to have, but what kind of language behavior it's going to have to
address. Trust me, I can tell you with absolute c
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message-
> From: Jefferson González [mailto:jgm...@gmail.com]
> Sent: Sunday, February 22, 2015 11:59 PM
> To: Stanislav Malyshev
> Cc: Etienne Kneuss; Anthony Ferrara; Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> 2015-02-22 16:38 GMT-04:00 Stanislav Malyshev :
>
>
> Yes, that's not the case, at least nobody ever showed that to be the
> case. In general, as JS example (among many others) shows, it is
> completely possible to have JIT without strict typing. In particular,
> coercive typing provides as much information as strict typing about
> variable type after passing the function boundary - the only
> difference
> is what happens _at_ the boundary and how the engine behaves
> when the
> types do not match, but I do not see where big performance
> difference
> would come from - the only possibility for different behavior would
> be
> if your app requires constant type juggling (checks are needed in
> strict
> mode anyway, since variables are not typed) - but in this case in strict
> mode you'd have to do manual type conversions, which aren't in any
> way
> faster than engine type conversions.
> So the case for JIT being somehow better with strict typing so far
> remains a myth without any substantiation.
>
>
>
>
> Well, strict on a JIT environment may haven't been proved, but it surely
> has
> been proved on statically compiled languages like C.
Jefferson,
Strict type hints will not make PHP even remotely similar or otherwise
comparable to a statically typed language like C. It will take totally
different facilities being added to PHP, which are not being considered.
Currently, a JIT in the
> most cases can't compete to the bare performance of a static compiled
> language, both in resources and CPU, so how is non strict better in that
> sense?
Nobody is saying it's better in that sense. Nobody is also suggesting that
a statically compiled language like C isn't a lot easier to optimize than a
dynamic language with JIT. What we are saying is that Strict type hints are
of no help making JIT any better or easier, compared to Dynamic/Coercive
hints. I provided what I believe to be detailed proof for that in my email
titled 'JIT'.
> I thought those checks could be optional if generated at call time, thats
> why I
> gave these 2 examples:
>
> calc(1, 5) -> no need for type checking or conversion, do a direct call
> calc("12", "15") -> calc(strToInt(value1), strToInt(value2)) calc($var1,
> $var2) -
> > needs type checking and conversion if required
That's the wrong comparison to make. We should be comparing the same calls
with the two systems, rather than one call in one system and a different one
in a different system.
Taking your example:
calc(1, 5) -> no need for type checking or conversion *in neither Strict
type hints nor Coercive/Dynamic type hints*, do a direct call. Identical
performance.
calc("1", "5") -> fails in strict type hints, succeeds in Dynamic/Coercive
type hints (cannot be optimized)
Again, this illustrates that the difference between the two is that of
*functionality*, not performance.
If you're saying that calc("1", "5") is slower than calc(1, 5) when using
dynamic type hints - then that would be correct, but also pretty meaningless
from a performance standpoint, if what you have are string values. And if
you have integer values, well then, we've already established there's no
difference between the two type hinting systems.
Typically, you obtain the data you need in a type that's not under your
control. You're getting data from the browser, database, filesystem, web
service or some algorithm - the type of the values you get is determined by
the API functions you're using to get the data from.
So what are your options if what you have in your hand is "1" and "5",
because that's how the APIs provided the data to you, as opposed to 1 and 5?
Before they can be added, they need to be converted to integer format,
whether this is done by explicitly casting them (likely outcome in case of a
strict type hint), casting them through a safe coercive STH, or letting
PHP's + operator implementation do it for you. The data needs to be
converted somewhere.
> So what you are saying is that there is no way of determining the type of
> a
> variable (only at runtime), as Zeev explained on the previous messages,
> since
> variables aren't typed, checks are mandatory either way.
There are ways to infer typing information both during compile time and also
create 'educated guess' as to what t
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
Anthony, I started writing this long response, but instead, I want to localize the whole discussion to the one true root difference. Your position on that difference is the basis for your entire case, and my position on this argument is the base for my entire case. There we go: > And note that this can only work with strict types since you can do the > necessary type inference and reconstruction (both forward from a function > call, and backwards before it). Please do explain how strict type hints help you do inference that you couldn't do with dynamic type hints. Ultimately, your whole argument hinges on that, but you mention it in parentheses almost as an afterthought. I claim the opposite - you cannot infer ANYTHING from Strict STH that you cannot infer from Coercive STH. Consequently, everything you've shown, down to the C-optimized version of strict_foo() can be implemented in the exact same way for very_lax_foo(). Being able to optimize away the value containers is not unique to languages with strict type hints. It's done in JavaScript JIT engines, and it was done in our JIT POC. > With lax (weak, coercive) types, the ability to do type reconstruction > drops > significantly. Because you can no longer do any backwards inference from > other function calls. Which means you can't prove if a type is stable in > most > cases (won't change). Therefore, you'll always have to allocate a ZVAL, > and > then the optimizations I showed above would stop working. Again, using the scientific method I'm familiar with, that would be a theory, and it would require proof. So far I haven't seen any proof, and I believe I pretty much proved the opposite with my example. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, February 23, 2015 1:35 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Zeev,
>
> >> And note that this can only work with strict types since you can do
> >> the necessary type inference and reconstruction (both forward from a
> >> function call, and backwards before it).
> >
> > Please do explain how strict type hints help you do inference that you
> > couldn't do with dynamic type hints. Ultimately, your whole argument
> > hinges on that, but you mention it in parentheses almost as an
> afterthought.
> > I claim the opposite - you cannot infer ANYTHING from Strict STH that
> > you cannot infer from Coercive STH. Consequently, everything you've
> > shown, down to the C-optimized version of strict_foo() can be
> > implemented in the exact same way for very_lax_foo(). Being able to
> > optimize away the value containers is not unique to languages with
> > strict type hints. It's done in JavaScript JIT engines, and it was done
> > in our
> JIT POC.
>
> I do here: http://news.php.net/php.internals/83504
>
> I'll re-state the specific part in this mail:
>
> function foo(int $int): int {
> return $int + 1;
> }
>
> function bar(int $something): int {
> $x = $something / 2;
> return foo($x);
> }
>
> ^^ In that case, without strict types, you'd have to generate code for
> both
> integer and float paths. With strict types, this code is invalid.
Ok, but how does that support your case? That alludes to the functionality
difference between strict STH and dynamic STH, and perhaps your Static
Analysis argument.
How does it help you generate better code code?
Suggesting that the nature of a type hint can help you determine what's the
value that's going to be passed to it is akin to saying that the size and
shape of a door can tell you something about the person or beast that's
standing on the other side. It just can't.
Let me illustrate it in a less colorful way.
Snippet 1:
... code that deals with $input ...
foo($input);
function foo(int $x)
{
...
}
Snippet 2:
... code that deals with $input ...
foo($input);
function foo(float $x)
{
...
}
Question:
What can you learn from the signatures of foo() in snippet 1 and 2 about the
type of $input? Does the fact I changed the function signature from snippet
1 to 2 somehow affects the type of $input? In what way?
If I understood you correctly, you're assuming that $input will too come
over using a strict type hint, which would tell you that it's an int and
therefore safe. But a coercive type hint will do the exact same job.
> You can tell because you know the function foo expects an integer. So you
> can infer that $x will have to have the type integer due to the future
> requirement. Which means the expression "$something / 2" must also be an
> integer. We know that's not the case, so we can raise an error here.
This is static analysis, not better code generation. And it boils down to a
functionality difference, not performance difference.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 2:25 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Ze'ev, It's Zeev, thanks :) > Because strict types makes that an error case. So I can then tell the user > to > fix it. Once they do (via cast, logic change, etc), I know the types of > every > variable the entire way through. So I can generate native code for both > calls > without using variants. I think we are indeed getting somewhere, I hope. If I understand correctly, effectively the flow you're talking about in your example is this: 1. The developers tries to run the program. 2. It fails because the static analyzer detects float being fed to an int. 3. The user changes the code to convert the input to int. 4. You can now optimize the whole flow better, since you know for a fact it's an int. Did I describe that correctly? > With strict typing at the foo() call site, it tells you that $input has to > be an int > or float (respectively between the snippets). I'm not following. Are you saying that because foo() expects an int or float respectively, $input has to be int or float? What if $input is really a string? Or a MySQL connection? Or are you saying that there was a strict type hint in the function that contains the call to foo(), so we know it's an int/float respectively? If so, how would it be any different with a coercive type hint? > I hope that makes my point a little clearer, It actually does, I hope. I think we are getting somewhere, but we're not quite there yet. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 3:02 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Zeev, > > > I think we are indeed getting somewhere, I hope. > > If I understand correctly, effectively the flow you're talking about > > in your example is this: > > > > 1. The developers tries to run the program. > > 2. It fails because the static analyzer detects float being fed to an > > int. > > 3. The user changes the code to convert the input to int. > > 4. You can now optimize the whole flow better, since you know for a > > fact it's an int. > > > > Did I describe that correctly? > > Partially. > > The static analysis and compilation would be pure AOT. So the errors would > be told to the user when they try to analyze the program, not run it. > Similar > to HHVM's hh_client. How about that then: 1. The developers runs a static analyzer on the program. 2. It fails because the static analyzer detects float being fed to an int. 3. The user changes the code to convert the input to int. 4. You can now optimize the whole flow better, since you know for a fact it's an int. Is that an accurate flow? > However, there could be a "runtime compiler" which compiles in PHP's > compile flow (leveraging opcache, etc). In that case, if the type > assertion > isn't stable, the function wouldn't be compiled (the external analyzer > would > error, here it just doesn't compile). Then the code would be run under the > Zend engine (and error when called). Got you. Is it fair to say that if we got to that case, it no longer matters what type of type hints we have? > >> With strict typing at the foo() call site, it tells you that $input > >> has to be an int or float (respectively between the snippets). > > > > I'm not following. > > Are you saying that because foo() expects an int or float > > respectively, $input has to be int or float? What if $input is really > > a string? Or a MySQL connection? > > So think of it as a graph. When you start the type analysis, there's one > edge > between $input and foo() with type mixed. Looking at foo's argument, you > can say that the type of that graph edge must be int. > Therefore it becomes an int. Then, when you look at $input, you see that > it > can be other things, and therefore there are unstable states which can > error > at runtime. So when you say it 'must be an int', what you mean is that you assume it needs to be an int, and attempt to either prove that or refute that. Is that correct? If you manage to prove it - you can generate optimal code. If you manage to refute that - the static analyzer will emit an error. If you can't determine - you defer to runtime. Is that correct? For now only focusing on these two parts so that we can make some progress; May come back to others later... Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 3:21 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Zeev, > > > >> Partially. > >> > >> The static analysis and compilation would be pure AOT. So the errors > >> would be told to the user when they try to analyze the program, not run > it. > >> Similar > >> to HHVM's hh_client. > > > > How about that then: > > > > 1. The developers runs a static analyzer on the program. > > 2. It fails because the static analyzer detects float being fed to an > > int. > > 3. The user changes the code to convert the input to int. > > 4. You can now optimize the whole flow better, since you know for a > > fact it's an int. > > > > Is that an accurate flow? > > Yes. At least for what I was talking about in this thread. OK. So the code after the fix would look like this: Let me explain how this could play out with coercive type hints: > >> However, there could be a "runtime compiler" which compiles in PHP's > >> compile flow (leveraging opcache, etc). In that case, if the type > >> assertion isn't stable, the function wouldn't be compiled (the > >> external analyzer would error, here it just doesn't compile). Then > >> the code would be run under the Zend engine (and error when called). > > > > Got you. Is it fair to say that if we got to that case, it no longer > > matters what type of type hints we have? > > Once you get to the end, no. Recki-CT proves that. Do you mean that the statement is unfair or that it no longer matters? If it's the former, can you elaborate as to why? > > The difference though is the journey. The static analyzer can reason about > far more code with strict types than it can without (due to the limited > number of possibilities presented at each call). So this leaves the > dilema: > compiled code that behaves slightly differently (what Recki does) or > whether > it always behaves the same. > > >> So think of it as a graph. When you start the type analysis, there's > >> one edge between $input and foo() with type mixed. Looking at foo's > >> argument, you can say that the type of that graph edge must be int. > >> Therefore it becomes an int. Then, when you look at $input, you see > >> that it can be other things, and therefore there are unstable states > >> which can error at runtime. > > > > So when you say it 'must be an int', what you mean is that you assume > > it needs to be an int, and attempt to either prove that or refute > > that. Is that correct? > > If you manage to prove it - you can generate optimal code. > > If you manage to refute that - the static analyzer will emit an error. > > If you can't determine - you defer to runtime. > > > > Is that correct? > > Basically yes. Let me describe here too how it may look with coercive hints. Instead of beginning with the assertion that it must be an int, we make no guess as to what it may be(*). We would use the very same methods you would use to prove or refute that it's an int, to determine whether it's an int. Our ability to deduce that it's an int is going to be identical to your ability to prove that it's an int. If we see that it comes from an int type hint, from an int typed function, etc. - we'd be able to generate the same ultra optimized C-level call. If we manage to deduce that it may be an int or a float, we can still create an ultra-optimized calling code that would deal with just these two cases, or call coerce_to_int(). If we deduce that it's a type that cannot be converted to an int (e.g. array or resource) - we can emit a compile-time error. And if we have no idea what it is, we emit a regular function call. Going back to that (*) from earlier, even if we're unable to deduce what it is, we can actually assume/hope that it'll be an integer and if it is - pass it on directly to the C implementation with a C level function call; And if not, go with the regular function call. The machine code you're left with is pretty much equivalent in case we reached the conclusion that the variable is an integer (which would be roughly in the same cases you're able to prove it that it is). The difference would be that it allows for the non-integer types to be accepted according to the coercion rules, which is a functional difference, not performance difference. Again, I'm not at all saying you can't do the optimizations you're saying you're going to do or already doing. In a way I'm saying the opposite - of course you can do them. We can do them as well with coercive type hints. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message-
> From: Jefferson Gonzalez [mailto:jgm...@gmail.com]
> Sent: Monday, February 23, 2015 3:58 AM
> To: Stanislav Malyshev; Anthony Ferrara
> Cc: Zeev Suraski; Jefferson Gonzalez; PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> How casting (int) could be such dangerous thing? Lets take for example
> this
> code:
>
> echo (int) "whats cooking!";
> echo intval("whats cooking");
>
> Both statements print 0, so how is casting unsafe???
One key premise behind both strict type hinting and coercive type hinting is
that conversions that lose data, or that 'invent' data, are typically
indicators of a bug in the code.
You're right that there's no risk of a segfault or buffer overflow from the
snippets you listed. But there are fair chances that if you fed $x into
round() and it contains "whats cooking" (string), your code contains a bug.
Coercive typing allows 'sensible' conversions to take place, so that if you
pass "35.7" (string) to round() it will be accepted without a problem.
Strict typing will disallow any input that is not of the exact type that the
function expects, so in strict mode, round() will reject it. The point that
was raised by Stas and others is that this is likely to push the user to
explicitly cast the string to float; Which from that point onwards, happily
accept "whats cooking", keeping the likely bug undetected.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 3:43 AM > To: Stanislav Malyshev > Cc: Zeev Suraski; Jefferson Gonzalez; PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Stas, > > >> It is still a performance advantage, because since we know the types > >> are stable at compile time, we can generate far more optimized code > >> (no variant types, native function calls, etc). > > > > I don't see where it comes from. So far you said that your compiler > > would reject some code. That doesn't generate any code, optimized or > > otherwise. For the code your compiler does not reject, still no > > advantage over dynamic model. > > It rejects code because doing code generation on the dynamic case is > significantly harder and more resource intensive. Could that be built in? > Sure. > But it's a very significant difference from generating the static code. I hope I demonstrated in the other email that lists how two use cases would look with coercive type hints, the strategies and implementation of doing the optimizations for those cases where we can infer the type in compile time, would be similar in cost, complexity and resource consumption to the optimizations you're talking about. Even if we keep the handling of all other types as AOTless/JITless, it would still have performance equivalent to the strict case, given inputs that the strict case accepts. Either way, I'm happy we all agree that equally-efficient code can be generated for the dynamic case, which is the point I was making in the Coercive typing RFC. We still have the gap on whether it's truly a lot harder and resource intensive - I don't think it is as we can do the very same things in compile-time - but that's a smaller gap that I personally care less about. I wanted it to be clear to everyone that we can reach the same level of optimizations for Coercive type hints as we can for Strict. > And even if we generated native code for the dynamic code, it would still > need variants, and hence ZPP at runtime. Hence the static code has a > significant performance benefit in that we can indeed bypass type checks > as > shown in the PECL example a few messages up (more than a few). We can only eliminate the ZPP structure during compile time if we know with certainty what the type is. If we do, we know that for both strict type hints and coercive type hints (i.e. we either managed to prove it's an int in the static analyzer in the strict case, or we managed to deduce what the type is in the coercive case). If we don't - we the ZPP structure it in exactly the same way. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, February 23, 2015 4:38 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Well, yes and no.
>
> In this simple example, you could generate the division as float division,
> then
> checking the mantissa to determine if it's an int.
>
> long bar(long something) {
> double x = something / 2;
> if (x != (double)(long)x) {
> raise_error();
> }
> return foo((long) x);
> }
>
> You're still doubling the number of CPU ops and adding at least one branch
> at
> runtime, but not a massive difference.
To be honest, I missed an important part in the semantics of the sample
code, the fact that the result of the division in bar() is sent to function
with an integer type hint, which means it may with Coercive STH just as it
would with Strict STH (in retrospect I now understand you alluded to that in
your replies to Stas, but was too tired to realize that). That means that
we could conduct identical static analysis, alerting the developer to the
exact same possible type mismatch in both Coercive STH and Strict STH. I
actually fail now to see how the process would be any different at all
between the two modes. This particular code requires changes in order to
work in all cases - semantic changes - probably either explicit casting to
int or - more likely - changing the type hints to float. In either of these
cases, we'd now have fully known types for the entire flow and could
optimize it to machine code equally well and equally easily, and with the
same number of resulting CPU ops.
> However in general you'd have to use something like div_function and use a
> union type of some sort. You mention this (about checking zval.type at
> runtime). My goal would be to avoid using unions at all (and hence no
> zval).
> Because that drastically simplifies both compiler and code generator
> design.
That would be our goal as well. And in most cases, the success ratio will
be the same between coercive and strict implementations. In that snippet
(which again, I misanalysed) - a static analyzer will be able to alert to
the same issue, prompting the developer to fix it (equally in both Coercive
and Strict). With the two probable fixes - an explicit cast to int, or the
more likely change of type hints across the sample from int to float - we'd
be able to conduct the same compile-time analysis and generate optimal,
ZVAL-free code in both Coercive and Strict STH.
> It's very much not about impossible.
I'm happy we have that clearly stated, as based on emails here and
elsewhere, it wasn't clear to a lot of people beforehand. Given identical
input source code, in all the cases where it's possible to generate C-level
calls with Strict, it will also be possible to generate C-level calls with
Coercive.
By the way, that misperception that it's possible to do optimizations with
Strict that aren't possible with Dynamic/Coercive doesn't have to do just
with assertions that were stated here or elsewhere. I've heard people
assuming that many years ago, effectively guessing that's the case without
having any meaningful understanding about execution engines or JIT, deducing
that strict type hints would somehow turn PHP into C in terms of our ability
to optimize.
> It's about complexity. Strict code is
> easier to reason about, it's easier to analyze and it's easier to
> code-generate
> because all of the reduced amount that you need to support. And we're not
> talking about making users change their code drastically. We're talking
> about
> -in many cases- minor tweaks.
The explicit casting risk has been beaten to death so I won't dive into it
yet again.
I think it boils down to strict STH accepting fewer inputs, which a static
analyzer can sometimes pick up, thereby prompting developers to be more
explicit in their choices of types - in turn providing more compile-time
type information and more restrictive at that - thereby making the code
easier for AOT to work on. It still holds that given the same
explicitly-typed code, AOT/JIT can do an identical job between Strict STH
and Coercive STH. The difference is that the Static Analyzer would be able
to alert you to some more rejections - because there would be more
rejections with Strict than there would be with Coercive - rejections that
would prompt you to change your code. I still think that the cases where a
static analyzer can provide more insight in Strict vs. Coercive are
relatively rare. Our ability to infer the type in compile time is identical
between both; In cases where we can clearly know with absolute confidence
that the type we have is the type the function
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message- > From: Joe Watkins [mailto:pthre...@pthreads.org] > Sent: Monday, February 23, 2015 10:03 AM > To: Jefferson Gonzalez > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Zeev, > > I missed the initial replies to this, just had a quick read through > (of the kind > you have first thing on a Monday morning). > > Essentially the problem is this: > > > My point is that we can do the very same optimizations with coercive > types as well - basically, that there is no delta. > >The problem is that an implementation that has to care about coercion, > one that has to care about nonsense input, has to generate considerably > more complex code, to manage that input or perform those coercions. Not necessarily. If you can infer the type with confidence, you can do away with coercion code altogether. If you can't, then you're not obligated to generate optimized paths for every possible input - you can just defer to the relevant coerce() function. It's very similar to what you'd be able to do with strict, except instead of calling coerce(), it would run a runtime type check that errors out on failure. The difference is that of functionality, not performance. >You may be able to perform some of the same optimizations, but the code > executed at runtime is going to be more complex to execute and to > generate, that is obviously true. Again, not necessarily. We shouldn't assume we'll generate machine code for all the possible flows. The code generated would be very similar in both strict and coercive cases. >The JIT Zend had needed to generate similarly complicated code and *it > was not faster than PHP, in the real world*, we are told. It depends on what kind of real world we're talking about here. For number crunching, it's super-fast with very tangible gains, and that's an understatement. Not sure if you saw my email from yesterday, but it shows 25x (2500%, no mistake) gains on bench.php, with zero changes to the code, and obviously, without type hints, strict or dynamic. With web apps we tested, there wasn't a tangible difference, but that doesn't (yet) mean much. We stopped most of the work on it when the PHPNG effort began. It may or may not be possible to squeeze more performance using JIT out of these apps, we won't know until we try again. >I'm not sure what you are arguing about, there is no point in > generating any > code that is not faster than Zend, and Zend just got a bunch faster. JIT might end up being about making PHP viable for more CPU-bound use cases, rather than speeding up existing Web workloads. But it's way too early to conclude that. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message- > From: Joe Watkins [mailto:pthre...@pthreads.org] > Sent: Monday, February 23, 2015 11:29 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Zeev, > > > If you can infer the type with confidence, you can do away with > > coercion > code altogether. > > > Maybe I'm ignorant of something, but isn't the only way you can begin to > infer the type with real confidence is by having strict typed parameters ? Not at all. You can definitely infer lots of type information without any type hints, strict or weak. bench.php wouldn't be 25x faster and Mandelbrot would not be as fast as an equivalent C program if we couldn't infer types without type hints. Take a look at it (Zend/bench.php) - much like you can, as a human, figure out that $i is an integer, and that $recen is a float, etc. - you can write code that will do that automatically (by taking a look at the assigned values, at the operators which are used, etc.) In general. If you haven't, please read my reply to Jefferson from yesterday: marc.info/?l=php-internals&m=142463029832159&w=2 It illustrates the point as to why not only are strict types not necessary to do type inference, they also don't provide you with additional data that can help you generate better code *assuming the same input source code*. The bets are off if you change your code and compare how the changed version runs in the Strict mode and the unmodified one runs in Coercive. But if you take the modified code and run it on both Strict and Coercive - you can reach the same results (except for the obvious, intentional functionality differences). Now, there may be cases that a static analyzer - that assumes strict rules - could prompt a developer to change their code (e.g. explicitly cast), and it's possible that after the change - the code could be better optimized. I'm not sure if these cases exist or not, but even if they do - after the code change, Strict and Coercive runtime implementations would be able to optimize the code equally well. It might actually make sense for a static analyzer to optionally employ strict rules even if we go for the coercive-only option - pointing the developer to where values in his code clearly switches types due to a type hint - as some sort of a performance tip. This would apply primarily in situations where you have values changing types back and forth and perhaps, with some developer attention - that could be avoided. > > If you can't, then you're not obligated to generate optimized paths for > every possible input - you can just defer to the relevant coerce() > function. > > If the parameters aren't strict but are typed then you need to travel > coercion > code paths somewhere, optimized inline, calling an API function, it makes > no > real difference. Correct. But you're comparing a situation where in Strict - the code would bail out and fail. Of course failure is faster than actually doing something :) The question is what the developer wants to do semantically. In most cases, with "32" (string) being passed to an integer type hinted argument, he'd want it to convert to 32 (setting aside the question on whether implicitly or explicitly). Which means that in strict - he'd have to do something along the lines of an explicit cast - and similarly, it could be optimized inline, call convert_to_long(), etc. The root difference is that of functionality, not performance. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message-
> From: Pavel Kouřil [mailto:pajou...@gmail.com]
> Sent: Monday, February 23, 2015 11:49 AM
> To: Joe Watkins
> Cc: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins
> wrote:
> > Zeev,
> >
> >> If you can infer the type with confidence, you can do away with
> >> coercion
> > code altogether.
> >
> > Maybe I'm ignorant of something, but isn't the only way you can begin
> > to infer the type with real confidence is by having strict typed
> > parameters ?
> >
> > This sounds like the kind of strict mode we're talking about, where no
> > coercion is necessary because inference is so reliable given a good
> > starting place (function entry with strictly typed parameters).
> >
> >> If you can't, then you're not obligated to generate optimized paths
> >> for
> > every possible input - you can just defer to the relevant coerce()
> > function.
> >
> > If the parameters aren't strict but are typed then you need to travel
> > coercion code paths somewhere, optimized inline, calling an API
> > function, it makes no real difference.
> >
> > I guess we are hedging our bets that having to travel those paths will
> > suck away so much performance, that it will make all of the effort
> > required to make any of this a reality seem, somehow ... wasted.
> >
> >> JIT might end up being about making PHP viable for more CPU-bound use
> > cases ...
> >
> > This is probably quite realistic.
> >
> > In case anyone is reading and thinks I'm using any of this to justify
> > dual mode, I'm not doing that. The original RFC justified it well
> > enough, I just happen to disagree with some of the assertions made in
> > this thread and or RFC.
> >
>
> Hello,
>
> if I understand the issue correctly, not even strongly typed parameters
> won't
> help you infer types of variables with real confidence?
>
> Imagine this piece of code:
> function foo(int $x) { $x = fnThatReturnsRandomScalarType(); return $x; }
Absolutely correct.
On the flip side, you can very often infer type without any type hints at
all. In reality we'd have to rely on that quite heavily, since code is not
only about - or even mostly about - function arguments. There are local
variables, function arguments can be reassigned and change type (as you
illustrated), etc. For example, from bench.php:
function simplecall() {
for ($i = 0; $i < 100; $i++)
strlen("hallo");
}
You can infer with full confidence that $i is an int without having any type
hint information for it. This is actually a remarkably common case.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Monday, February 23, 2015 1:54 PM > To: Joe Watkins > Cc: Etienne Kneuss; Jefferson Gonzalez; PHP internals; Anthony Ferrara; > Zeev > Suraski > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > > I think our approches were very similar and leaded us to simular > decisions, > however we alredy tried jit-ing bench.php with type hints (strict). While > JIT > itselv makes bench.php about 5 times faster, type hints adds about 2%. > Strict > or weak make no difference at all. Woops, it was Mandelbrot that was 25x faster with JIT. bench.php as a whole was 'only' 5 times faster as Dmitry stated. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 4:14 PM > To: Zeev Suraski > Cc: Joe Watkins; PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Zeev, > > >> Maybe I'm ignorant of something, but isn't the only way you can begin > >> to infer the type with real confidence is by having strict typed > >> parameters > ? > > > > Not at all. You can definitely infer lots of type information without > > any type hints, strict or weak. bench.php wouldn't be 25x faster and > > Mandelbrot would not be as fast as an equivalent C program if we > > couldn't infer types without type hints. Take a look at it > > (Zend/bench.php) - much like you can, as a human, figure out that $i > > is an integer, and that $recen is a float, etc. - you can write code > > that will do that automatically (by taking a look at the assigned > > values, at > the operators which are used, etc.) In general. > > Yes, but mandel() from bench.php isn't generic code. It is a subset of > valid > code. One that wouldn't need any changes to move to strict mode. I'm not sure what that means. mandel() is an example in the very same way that foo() and bar() you presented were examples. It also happens to be a real world example showing Joe that not only is it possible to do type inference without strict typing (who asked " isn't the only way you can begin to infer the type with real confidence is by having strict typed parameters?") - but it's possible to do a great job at it, too. > Additionally: "would not be as fast as an equivalent C program". I > compiled > mandel() using C (via PECL). It wasn't 25x faster, it was 75734.13830x > faster > (3000x with -O0). So no, you're way off from C speed. Those were our results: PHPNG-JIT (JIT=on) 0.011 (25 times faster than php-7) gcc -O2 (4.9.2)0.013 gcc -O0 (4.9.2)0.022 PHP-7 0.281 (15 times faster than php-5.0) PHP-5.60.379 PHP-5.50.383 PHP-5.40.406 PHP-5.30.855 PHP-5.21.096 PHP-5.11.217 PHP-4.44.209 PHP-5.04.434 Something broken in your setup. BTW, I'm not claiming our JIT is faster than gcc. It's at the margin of error level. > > If you haven't, please read my reply to Jefferson from yesterday: > > marc.info/?l=php-internals&m=142463029832159&w=2 > > It illustrates the point as to why not only are strict types not > > necessary to do type inference, they also don't provide you with > > additional data that can help you generate better code *assuming the > same input source code*. > > The bets are off if you change your code and compare how the changed > > version runs in the Strict mode and the unmodified one runs in > > Coercive. But if you take the modified code and run it on both Strict > > and Coercive - you can reach the same results (except for the obvious, > > intentional functionality differences). > > Again, please make it clear to people that you're talking about special > cases > of userland code, where the rest of us are talking about general cases. But I'm not. We are all talking about general cases. The code snippets in the email I sent to Jefferson are as generic as they could possibly be, allowing you to fill the code blocks with anything to your heart's content - the outcome would not change. We're in an endless repetitive ping pong here, so I'm going to summarize this thread from my POV: 1. For a given input source file, there is zero difference in terms of AOT/JIT between Strict mode and Coercive mode. In both cases, the level of type inference you can do is identical - and cases where you can determine the type of the arguments being passed conclusively can turn into a C-style call instead of a PHP call. Cases where you cannot determine that would be conceptually similar between Strict and Coercive, except Strict would result in a failure in case it detects the wrong type at runtime, while Coercive may succeed. Intended functional difference, no performance difference. 2. Since Strict rejects any wrongly typed value, in cases where you can determine conclusively that the wrong type may make it into a certain function, you can alert to that fact, prompting the developer to change it. Depending on the nature of the change, it *might* result in the ability to better optimize the code, although so far, there
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > Sent: Monday, February 23, 2015 6:54 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski wrote: > > > Additional options we could entertain are: > > 5. Go for just E_DEPRECATED in 7.0. Change E_DEPRECATED to > E_RECOVERABLE_ERROR in 7.1/7.2/8.0 (TBD). > > 6. Same as #5, but also provide a mechanism similar to declare() as > the temporary measure for strict campers to explicitly ask for > E_RECOVERABLE_ERROR’s to be triggered. They will no longer be necessary > when we change E_DEPRECATED to E_RECOVERABLE_ERROR in 7.1/7.2/8.0. > > > 5. BC Break too big leading to a Python2/3 situation, low adoption of > PHP7, > something that especially you couldn't want given that the perf > improvements are what keeps PHP on level with HHVM. This automatically > applies to all internal functions regardless if userland uses typehints or > not, > wordpress will not work with this anymore, no performance comparisons > anymore. I don't see how that would affect PHP 7 adoption at all actually. You can just disable E_DEPRECATED and your upgrade would be clean. Technically it would have to wait to PHP 8 before we change it to E_RECOVERABLE_ERROR, give users several years to migrate. Given we're talking about coercive rules and not strict rules, I actually don't expect that many failures (initial tests of Francois' patch results in 8% failures in our unit tests, and that's before tweaking the rules in any way (and apparently, at least some of them have to do with bugs in internal functions that can be easily fixed). It doesn't strike me as a worse migration than we did getting rid of magic_quotes or safe_mode. It can be done. I'm personally now leaning towards this option as the most viable one. > 6. Ok, so this is now getting very similar like v5 of the STH, but still > with much > more BC breaks. Not at all. With the Dual Mode RFC, we're going to have declare() and two distinct modes even in 10 and 20 years from now, for all eternity. It's a new feature that's here to say. With this, these declare()'s are a migration feature, that will be gone in several years. The endgame is completely different. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > Sent: Monday, February 23, 2015 7:20 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Just disabling E_DEPRECATED is hiding bugs now. It's an extreme interpretation. Deprecated features are not bugs over-night. We never considered it that way. E_DEPRECATED notices aren't bugs - they're friendly messages that the feature you relied on has limited lifespan left in it. The error gets triggered > *because* somebody uses the wrong coercion rules, if i hide this, how am i > going to fix it? You're going to have several years to fix it. You could do it during a bug squash, at your leisure every once in a while, or the first day after PHP 7 comes out. Just like with any other deprecated feature. > Compare this to Smarty/FPDF/TCPDF. Extremly wide adoption libraries, still > php v4 code. > They throw strict errors and notices like nothing you have ever seen > before, > but nobody talks about turning them into errors in PHP7/8. First, I've seen some pretty horrible stuff, so don't assume :) But to the point, this: wiki.php.net/rfc/reclassify_e_strict I'm not saying I necessarily support this RFC, but there's at least one person talking about exactly the stuff supposedly nobody's talking about, and that's without anything remotely close to the tangible benefits that doing the internal function migration would bring. > Furthermore, you said before this will be only 1-2 years, now until 8 we > have > another 8-10 years. There's no rulebook saying a major version needs to come out every 10 years. PHP 3 came out in 1998, PHP 4 came out in 2000, and PHP 5 came out in 2004. PHP 5.3, which arguably should have been a major version, came out in 2009. I think we should announce our plans for PHP 8 announced around the same time as we release PHP 7. Not a concrete timeline like the one we have for 7 right now, but high level plans. Given we're likely going to work on JIT right after 7 comes out, we're going to have a trigger for 8 much sooner than 2025 (not that personally I think we need a huge trigger for a major version, but that's a different story). The 1 year figure is in the case we decide to change E_DEPRECATED to E_RECOVERABLE_ERROR in 7.1 (which is an unlikely outcome). The 2 year figure is realistic for PHP 8 given JIT, but if it's optimistic, it may be 3 and not 2. I doubt PHP 8 will take much longer than that, and can't imagine 10 years. > 8% is alot. Now you are lucky that you have unit tests. The kind of code > that > will rely on this conversion probably does not have a single test. I'm talking about the PHP unit test suite, and while 8% failure rate on a test suite is generally a lot, I wouldn't consider it a high number for such an impactful patch that has not yet been tuned. Also assume we have until the end of the year to potentially tweak certain internal functions to be more lax than the rules they currently expose, which may make sense in some cases where we may find widespread breakage associated with specific APIs. I believe we can get it much lower than 8% by tweaking the rules and tweaking some internal functions. Regarding other apps - many of the major apps today do have unit test suites, and I'm seeing unit and system tests a lot more today than 5 or 10 years ago. We'll only truly know where we stand once we actually try running some of the major apps and real world code see how many E_DEPRECATED messages we're getting. If we see a few dozen E_DEPRECATED's for a decent size apps - the feasibility of migrating it (whether immediately, during the 2-3 year term or when people move to 8 and are forced to do so) is there. Not unlike many of the countless other features we've deprecated in 7 - most of which for no reason other than code tidiness. > magic quotes has a workaround you can put into an auto_prepend_file, > *magically* making it work this way before again. > This changes here have no workaround to keep the old mode. magic_quotes_gpc did, magic_quotes_runtime did not. safe_mode didn't either, and it was extremely widely used. > I'm personally now leaning towards this option as the most viable > one. > > > I agree if we can avoid an INI setting, but this will surely lead to a > Python 2/3 > situation. I don't think it will. But instead of guessing, we should try the patch with some real world apps and find out. I think that if we find out we can migrate Drupal (or whatever) in a couple of days or even a couple of weeks to be E_DEPRECATED free - this approach is very viable. If it requires months and months of updates, it'll be a different story. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > Sent: Monday, February 23, 2015 9:35 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > > > On Mon, Feb 23, 2015 at 7:09 PM, Zeev Suraski wrote: > You're going to have several years to fix it. You could do it during a > bug > squash, at your leisure every once in a while, or the first day after > PHP 7 > comes out. Just like with any other deprecated feature. > > > > This is not how legacy code migrations work at all. You don't migrate > 100KLOC code just because the php version isnt compatible anymore. > You just don't upgrade. Now people might upgrade to PHP 7 because its > "just" E_DEPRECATED. Benjamin, If you've been for a while on internals, you should know I'm a downwards compatibility freak. You don't need to explain to me about the nature of upgrades and how much downwards compatibility is important. But here, I disagree with you, for several reasons. If we implement this in PHP 7, assuming the most aggressive 2 year timeline for 8, 7.x will be supported until late 2019, and if it's a 3 cycle - late 2020. That's actually 5 years to migrate. Ample time for those who care about upgrades. Secondly, for some reason you appear very opinionated that this will result in huge breakage, even though we don't yet have any evidence to suggest it'd be the case, at least not yet. Thirdly, there are major reasons to upgrade to PHP 7, and we'd hopefully have some major reasons for people to upgrade for 8. There are going to be substantial carrots next to that breakage stick. Last, you appear to represent the 'can't be bothered' crowd, which I agree, is fairly large. But that crowd typically just doesn't upgrade, unless something or someone twists their arm. They don't upgrade even when there's no or very little compatibility breakage. That's why 5.3 is still so popular, and 5.2 isn't rare to find. Let alone 5.4. We have a track record that suggests that compatibility breakage slows adoption down, but it does not kill it as you suggest. > But they will not upgrade their code to PHP 7.1 or 8 then. Sooner or later they'd have to, if they want to maintain security. If they don't - it will not be the first time in history that people are negligent about their deployment (as the fact there are so many 5.2/5.3 deployments still out there proves), nothing unique for 7/7.1. > How can you compare them? > > This changes E_STRICT to a E_WARNING. This is completely different than > changing E_DEPRECATED to E_RECOVERABLE_ERROR. If you read the RFC thoroughly, you'd see it contains elements that are exactly the same thing: * Promote to E_DEPRECATED if there is intent to remove this functionality in the future. // Non-static method Foo::method() should not be called statically Proposed resolution: Convert to E_DEPRECATED Possible alternative: Convert to E_DEPRECATED, if we intend to make this a fatal error in the future. > The first only requires to wrap an old library in $old = > error_reporting(0); > library(); error_reprting($old); > > The second leads to a fatal error. Are you seriously explaining to me how zend_error() works? :) > Ok, lets say 4-5 years. Given the lagging adoption of PHP major versions, > double this situation to 8-10 years in the wild. I do believe a 2-3 timeline for 8 (from when 7 is released) is a lot more likely than 4-5. The last time we had a major version was, as you know, 11 years ago. We can't deduce anything about adoption numbers from what we had back then. We're also on a much more aggressive timeline nowadays, with support for each version stopping 3 years from when it gets initially released. At least based on what I'm seeing, adoption cycles appear to be significantly shorter than they used to be (1-3 years, not 4-5). Of course, much like there are still users of 5.3, we're likely to have users of 7.0 even in 2025. That's not the point, and shouldn't play a role in the decision - it'd happen regardless. > Speaking as a consultant who helps people fix their legacy code I am > biased. > In my world nobody has tests. > And even those that have on their prorpiortary apps seldom have higher > coverage than 30-50%. Only very few have 80%. > > You cant compare open source code to what is out there, wordpress/drupal > is good code compared to all the propriortary code out there. I agree. But I am seeing better testing even in the darker corners of our tech world. Regardless, your customers either stick around with the old versions, or find a way to one way or another test the app - be it manually or otherwise. The former camp won't
[PHP-DEV] Coercive STH RFC updated
v0.24 now focuses on one migration strategy – E_DEPRECATED for PHP 7.x, and E_RECOVERABLE_ERROR (or likely exceptions) for PHP 8.x and later. wiki.php.net/rfc/coercive_sth We’ll update the implementation accordingly, and hopefully be able to start testing to see how bad of a breakage we’re seeing. For that reason for now I’m not yet updating the conversion rules – we’d all be a lot smarter after we’ve tried this with both our test suite and some real world apps. Thanks, Zeev
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
Anthony, Thanks for testing, but it's a bit premature to jump to conclusions. First, disabling phar is in the patch instructions at github.com/php/php-src/pull/1110 - it's a bug in phar that needs to be fixed. We'll address it. Secondly, as was obvious both from Francois' email and mine, this is just an initial patch, and yes, we know it presently fails 8% of the test cases (as I stated a few hours ago in an email to Benjamin). I still think it's not a bad start at all; It would be a pretty bad ending, but I think we can tweak the rules to get a lot less breakage. If you're up for it, you can experiment with the many the 12 configuration switches that govern this patch - but even that is a bit premature. Let people who actually want this RFC to pass try and tweak the patch first :) Thirdly, as I shared earlier, the RFC was updated to go for E_DEPRECATED in PHP 7, which means there would be zero breakage in PHP 7, and ample time for people to migrate whatever issues this would introduce to their code until PHP 8. All functionality changes will go through the E_DEPRECATED cycle, exactly like the stuff that got removed in PHP 7. Last, we don't yet have an answer to your question about the billions of lines of code out there. But as I told to Benjamin, we have every intention to try the patch out on some real world apps and see how it performs. Let me assure you that if we find that there are hundreds of issues trying to get common apps to work, after we tweak the rules - I'll either retract the RFC or the very least rethink the internal functions part of it. Zeev > -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Tuesday, February 24, 2015 12:25 AM > To: Zeev Suraski > Cc: Benjamin Eberlei; PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > > Secondly, for some reason you appear very opinionated that this will > > result in huge breakage, even though we don't yet have any evidence to > > suggest it'd be the case, at least not yet. > > So I tried to compile the patch to get a real-world idea of the breaks. > > The first thing, PHP's own phar generator included in the make file fails > due > to the new restricted hints (based on the patch provided). > (I had to rebuild with --disable-phar to get it to build). > > Let me make that perfectly clear: under these changes you cannot do a > default compile of PHP due to BC breaks. > > Let's take a look at the numbers. I just ran a > ./configure --enable-mbstring -- > disable-phar --enable-debug, and got the following test results: > > Number of tests : 13653 9008 > Tests skipped : 4645 ( 34.0%) > Tests warned:0 ( 0.0%) ( 0.0%) > Tests failed: 697 ( 5.1%) ( 7.7%) > Expected fail : 32 ( 0.2%) ( 0.4%) > Tests passed: 8279 ( 60.6%) ( 91.9%) > - > Time taken : 954 seconds > > 7.7% of the internal test suite is extremely significant. That's just > short of 700 > tests on a reasonably default install. > > So I recompiled with a bunch more extensions: > > Number of tests : 13716 10343 > Tests failed: 811 ( 5.9%) ( 7.8%) > > And that's for PHP's suite. What about for the hundreds of millions of > lines of > code of untested apps out there? > > I tried running Symfony 2's test suite, but couldn't. Because: > > $ ../php-src/sapi/cli/php vendor/bin/phpunit > > Warning: debug_backtrace() expects parameter 1 to be integer, boolean > given in Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line > 58 > > Warning: array_shift() expects parameter 1 to be array, null given in > Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line 59 > > Warning: Invalid argument supplied for foreach() in > Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line 61 > > Fatal error: Uncaught strpos() expects parameter 1 to be string, boolean > given > > Symfony2/src/Symfony/Bridge/PhpUnit/DeprecationErrorHandler.php:38 > > thrown in Symfony2/vendor/phpunit/phpunit/src/Framework/TestSuite.php > on line 871 > > > So yeah, to say "major BC issues" is the literal definition of an > understatement. > > > Thirdly, there are major reasons to upgrade to PHP 7, and we'd > > hopefully have some major reasons for people to upgrade for 8. There > > are going to be substantial carrots next to that breakage stick. > > Yes, and if we can avoid giving people breaks they can't trivially avoid > (via a > "compatibility checker" script, like minor syntax changes), then we&
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Rowan Collins [mailto:rowan.coll...@gmail.com] > Sent: Tuesday, February 24, 2015 12:48 AM > To: Pierre Joye; Anthony Ferrara > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > On 22 February 2015 23:56:18 GMT, Pierre Joye > wrote: > >Can you all of you stop this madness with moving discussions off list? > > > >It is detestable, against almost all openness and principles behind an > >oss project like php. If we can't discuss anymore design, plans, ideas > >etc on the list then we are doomed, for good. > > I'm sorry, but I just don't agree. This list is extremely high traffic at > the > moment, and the idea that recording every word of every discussion is the > be > all and end all of an open project is nonsense. Just as the entire list > doesn't > need to hear every word you say to your rubber duck, it doesn't need to > see > every quickfire thought of a collaboration or personal debate. Saying "I > was > just chatting to X about..." isn't that far removed from "I was just > thinking > about..." > > Now, that's not to say that people should disappear off into private > discussion for weeks and emerge with a polished product; clearly, > important > points need to be brought to the list promptly, and extra views solicited. > And > if the intention of going off-list was to hide a discussion from other > participants, that is wrong. But I see no evidence of either fault here. > > It seems to me perfectly desirable for people to go away and hash a few > things out over a whiteboard or a beer, virtual or otherwise, then present > a > full and prompt summary to the wider community. Done right, it actually > gives a *better* chance for other participants to follow the discussion, > because they don't have to devote hours to reading every word, but are > instead alerted to salient points they might want to think about and > respond > to further. I literally couldn't have put it better myself. Wholeheartedly agree. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive Scalar Type Hints RFC
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Tuesday, February 24, 2015 1:12 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Well, I am concerned at this error rate we're seeing that we won't cause > significant perf degradation due to the errors (even with reporting=0). > And > that's not mentioning log files. I'd say that's a feature - excellent motivation to fix these warnings! :) > > Last, we don't yet have an answer to your question about the billions > > of lines of code out there. But as I told to Benjamin, we have every > > intention to try the patch out on some real world apps and see how it > performs. > > > > Let me assure you that if we find that there are hundreds of issues > > trying to get common apps to work, after we tweak the rules - I'll > > either retract the RFC or the very least rethink the internal functions > > part of > it. > > Sounds great. My concern here though is that my instinct says that either > the > rules are going to come out so similar to today's rules as to not be > effective, > or break enough code that it's not worth it. > > Please continue the patch, and let's test iterations. I just don't see > where the > magic line will be (not breaking too much while providing enough benefit > to > please the proponents of strict types). I hope we can find that middle ground, triggering a reasonable number of issues, that will actually gradually push people towards stricter code. But I agree that the jury is still out on whether that's possible. I think diving into some of the found issues is as interesting as counting the number of failures. Are we (with some tweaks) onto a gold mine of potential issues here, or a torrent of noise? Anyway, we'll see. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks
> -Original Message- > From: François Laupretre [mailto:franc...@php.net] > Sent: Wednesday, February 25, 2015 3:20 AM > To: 'Pierre Joye' > Cc: 'Yasuo Ohgaki'; 'Zeev Suraski'; 'Anthony Ferrara'; 'PHP internals' > Subject: RE: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks > > Hi, > > > De : Pierre Joye [mailto:pierre@gmail.com] > > > > How do you test apps with actual production data? What a given code is > > being fed with in production, everywhere, using random > > application&users specific data or inputs. > > I personally have no codebase to test. These results come from a simple > PHP > core 'make test, probably not representative of a real application, I > agree. > > I expected ML members to try the tool on their codebase and return > numbers but, as usual, after everyone asked for a BC break evaluation > tool, > now it is here and nobody uses it. I know that I will be testing it with a number of real world apps. Let's not set the bar here higher than what we have for all other RFCs. It's not as if we test the entire planet codebase every time we make a potentially dangerous change, and PHP 7 has plenty of those. We test a (fairly representative) sample of real world code through some real world apps, framework tests and our own test suite; Additional list members and users will test it with their apps and provide feedback, etc. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] The Game Theory of Scalar Type Hint Voting
> -Original Message> From: Leigh [mailto:lei...@gmail.com] > Sent: Tuesday, February 24, 2015 2:56 PM > To: Albert Casademont Filella > Cc: Benjamin Eberlei; PHP Internals > Subject: Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting > > On 23 February 2015 at 21:15, Albert Casademont Filella > wrote: > > I like it! That's what I proposed to Anthony (and Andrea before) > > before Zeev presented their alternative, to held a double vote on the > > strict vs weak feature. It was not met with much enthusiasm, hope they > > change their minds with your proposal! > > Except a dual vote is probably not going to work in favour of strict vs. > weak. > > Why would anyone who wants purely strict vote for "Yes (strict)", when > they > know that "Yes (weak)" is going to have the majority. It boils down to > voting > Yes for something you don't want. I don't think it will convert votes at > all. > _If_ I wanted _strict only_ and I was presented with "Yes (strict)", "Yes > (weak)", and "No" and could see the weak vote winning by a clear margin, I > would vote No. Leigh, There isn't a weak-only proposal on the table. There's the original one (dual mode) and the coercive one. Both have both strict and dynamic elements in them. I think that what Anthony proposed about a week or so ago, of having both votes, and if both pass 2/3 - have another vote to choose between them (where a simple majority wins) - makes the most sense in this uncharted territory. I think that opening the votes at the same time is probably a good idea. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
> -Original Message- > From: Shashank Kumar [mailto:shashankkumar...@gmail.com] > Sent: Wednesday, February 25, 2015 2:54 PM > To: Dmitry Stogov > Cc: Anthony Ferrara; internals@lists.php.net > Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5 > > On Wed, Feb 25, 2015 at 4:30 AM, Dmitry Stogov > wrote: > > As I understand the proposal and above example, it's possible to change > the > 'strict_type' settings per file. > So, for an enterprise application being developed over many years, it's a > very > realistic scenario that this setting will be different in different files > especially > if coding conventions are not followed (happens very often). > > Does that mean when reading or writing code, in addition to checking the > signature of a function, I have to check the 'strict_types' setting at the > top as > well, to understand how that signature behaves? Not quite; You need to check the strict_types setting not where the function is defined, but where the function call is being made. It means that if you're editing other people's code, you first need to check what mode you're at, as it will determine the semantics of function calls in the file you're editing. Independent of the issues I see with strict types themselves, I think the concept of a dual mode has two substantial disadvantages: - It's an extra element to worry about when determining what your code will behave like. Yes, it's self-contained in the file - which is an advantage of INI entries, but it's still another thing to worry about. - As your question suggests, I think we have substantial evidence that the nature of this dual mode will be confusing to users. And we're not talking about the average users - we're talking about internals@ subscribers, some of which are big community leaders (sorry Matthew :). Combined, it's additional cognitive burden on the developer base, and it may also be divisive (e.g. "I only use libraries written with strict mode" or vice versa). That's why in the Coercive RFC we sought to find a combined ruleset that does away with these disadvantages, while doing its best to cater to the key needs of both camps, with the endgame being having just one camp. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
> -Original Message- > From: Theodore Brown [mailto:theodor...@outlook.com] > Sent: Thursday, February 26, 2015 5:29 PM > To: internals@lists.php.net > Subject: [PHP-DEV] A different user perspective on scalar type declarations > > I am a full-time PHP developer responsible for maintaining several large > enterprise applications, as well as a number of libraries and personal apps. > I have been following the scalar type proposals quite closely, as along with > return type declarations, scalar types have the potential to reduce errors, > simplify API documentation, and improve static code analysis. > > I am in favor of Anthony's Scalar Type Declarations RFC, for two simple > reasons: > > 1. It doesn't change the behavior of existing weak types. > > PHP has long had an emphasis on backwards compatibility, and I'm worried > that those not in favor of strict types are treating backwards compatibility > more recklessly than they otherwise would in their fervor to avoid two ways > of handling scalar types. In my experience dealing with large enterprise apps, > however, there are hundreds of places where code relies on GET/POST > parameters being automatically trimmed when passed to a function > expecting an integer. > The current coercive proposal would deprecate this and later make it an > error. > To avoid these notices/errors when upgrading, developers may take the > "easy" > route of casting any input passed to a function expecting an int or float. > This is the same "too strict may lead to too lax" problem pointed out by the > coercive RFC itself. There's a reason that integer handling was actually > *relaxed* back in PHP 5.1 (see > http://php.net/manual/en/migration51.integer-parameters.php). > Why suddenly make the default more strict again? > > I am not against tightening up some of the default weak conversions (e.g. to > not allow "99 bugs" for an int type), but in my opinion this should be done > very carefully, and separately from any scalar type declaration proposal. > Major changes to the casting rules have the potential to seriously harm PHP > 7 adoption, especially in enterprises with large amounts of legacy code. The > Scalar Type Declarations v0.5 RFC has the advantage here because it "just > works" when type hints are added to existing code in the default weak mode. You may have a point there. As Francois said, he was in favor of allowing leading and trailing spaces. I'll definitely reconsider. Would love to hear any additional feedback you may have about the conversion rules! My goal is to balance the 'Just works' aspect with the strict aspect, and still be able to put it into one rule-set, because I believe this has some inherent advantages. > 2. Strict types are important in some cases. > > When it comes to authentication and financial calculations (a couple of areas > I routinely deal with) it is extremely important that errors are caught and > fixed early in the development process. In financial or security-sensitive > code, I would *want* any value with the wrong type (even a string like "26") > to be flagged as an error when passed to a function expecting an integer. I agree completely; However, such use cases like this are a lot less common than the situations where you do want sensible coercion to be allowed. Not introducing language constructs to support strict typing doesn't mean I think it's never useful. I think it's at the level where it's better to leave it up to (very very simple) custom code, in the form of if (!is_int($foo)) errorout();, as opposed to introducing a whole 2nd mode into the language, with cognitive burden it brings. When I read Anthony's comment about the random number generators a couple of days ago: "I think the case you have to look at here is the target audience. Are you looking to be all things to all users? Or are you attempting to be an opinionated tool to help the 99%. Along with password_hash, I think this random library serves the 99%." I couldn't help but think the very same could be said about strict type hints (paraphrasing it myself, "I think the case we have to look at here is the target audience. Are we looking to be all things to all users? Or are we attempting to be an opinionated tool to help the 99%. With coercive types I think we serve the 99%." - whether it's 99% or 95% or 90% is negotiable - but it doesn't change the takeaway, I think). Now, the same can't be said when we use weak types. Weak type hints are completely useless for developers who want strict type hints, as their behavior is completely off from what they expect, and they'd never use them. But with the newly proposed coercive type hints - the gap narrows radically. The most common real world use cases strict campers brought up in the past as problematic with weak types - are gone. We're still left with some useful use cases for strict, but not at the level where it makes sense to add language-level support, especially in the form of dual mode, with all
RE: [PHP-DEV] A different user perspective on scalar type declarations
> -Original Message- > From: Dan Ackroyd [mailto:dan...@basereality.com] > Sent: Thursday, February 26, 2015 8:49 PM > To: Zeev Suraski > Cc: Theodore Brown; internals@lists.php.net > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > On 26 February 2015 at 17:48, Zeev Suraski wrote: > >> From: Theodore Brown [mailto:theodor...@outlook.com] 2. Strict types > >> are important in some cases. > >> > >> I would *want* any value with the wrong type (even a string like > > "26") > >> to be flagged as an error when passed to a function expecting an > > integer. > > > > > > I agree completely; However, such use cases like this are a lot less > > common than the situations where you do want sensible coercion to be > > allowed. > > > That's just not true on medium to large code bases, and if you think > that's > true it's possibly an explanation of why you don't see why people want > strict > types so much. > > In most applications, the part of the code that is exposed to the outside > world and has to convert strings or unknown types into known types is a > very > small layer at the outside edge of the application. > > The vast majority of code written for non-trivial applications has no > contact > with the outside world. Instead it only communicates to other layers > inside > the application where the types required are fully known, and so the > parameters passed should already be in the correct type. And so type > coercion is at best unneeded, and usually not wanted. > > I can understand why people might only want to use weak types for their > code base, but for you to continually dismiss people's desire for strict > types > after all this has been explained to you multiple times is very > depressing. First, I'd like to point out that I'm not talking about 'weak' (dynamic) typing, but the new coercive typing rules. The coercive typing rules are a lot stricter than the dynamic conversion rules that are employed throughout PHP. Now, when you mention the outside the world - what are you referring to? If you only refer to user input, then I agree. But if you add data sources - such as databases, web services, filesystem and others - then I disagree. Even in large projects, PHP interacts predominantly with such data sources (as well as user input, of course) - and these all provide data predominantly as strings. Pure computations with no feed of outside data are not nearly as common a use case for PHP (and web apps/services in general). Coercive typing is a much better fit not just handling user data - but also handling all kinds of input data, regardless of where it comes from. Strict is useful in narrow cases - mainly math-intensive computations of different sorts. That's a valid but not nearly as common a use case for PHP. Given that a 2nd mode comes at a price (complexity, people assuming it is what it's not, further technological division) - it's just not worth it. We need to aim for the one mode that caters to the 90+%, and not try to be everything to everyone at the cost of much increased complexity, not when they can very easily implement it in very simplistic and easily optimizable custom code. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 26, 2015 9:29 PM > To: Mike Willbanks > Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Mike, > > One point of clarification: > > > This is true, however, the types that you are receiving back form a > > multitude of data sources might be in a mixed format (databases for > > example often provide representation back as a string, non-json based > > web > services > > provide mainly as a string, etc). While I know what my data looks like > > and I know I am always going to get a "string" integer back I do not > > want to have to type cast this each and every time. Or that I have a > boolean > > integer representation that is in a string... You get the point. Sure, > > I > > could certainly go in and take 5 minutes and cast each one but I'm not > > certain why the purpose is there... It specifically changes the > > determination that PHP is a weakly typed language and all of a sudden > > I now need to care that my string integer boolean is not actually a > > boolean. > > It's funny that you bring up boolean... > > With the current coercive proposal, you will still need to worry about the > types: https://wiki.php.net/rfc/coercive_sth#coercion_rules That's true, but a lot, lot less. > Passing boolean(false) where an integer is expected will generate an > error. > This is a common practice, specifically around internal functions. > Example: > https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9f > e8916859a07430b94cf42/src/Util/ErrorHandler.php#L58 It's actually not nearly as common as one might think, and arguably - it's may be hiding bug or at least some misunderstanding about the semantics of the argument (not always, but sometimes). Warning about it (as deprecated) makes perfect sense. I'm going to send some data from real world apps later today or early tomorrow. Spoiler - not a lot of breakage at all, and coercive rules seem to have a remarkably good signal to noise ratio. > The difference is with the dual-mode RFC you can choose not to have to > cast > and keep everything as-is today (or more specifically, you need to > explicitly > choose strict mode). And you can have user-land behave identically to > internals **in both cases**. Put another way, coercive gets to keep a single, sensible conversion rule-set in PHP - with relatively minor updates needed over the course of several years. And contrary to what might be implied here, it would require a LOT less casting - while still taking advantage of much better data sanitation. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 26, 2015 9:54 PM > To: Zeev Suraski > Cc: Mike Willbanks; Dan Ackroyd; Theodore Brown; internals@lists.php.net > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Zeev, > > >> With the current coercive proposal, you will still need to worry > >> about the > >> types: https://wiki.php.net/rfc/coercive_sth#coercion_rules > > > > That's true, but a lot, lot less. > > We apparently have a different definition of "less". Your proposal > requires > you to worry about every type in every line of code that ever existed. > Yes, > there are fewer dangerous type change errors, but you need to look at > every > line of your application to find them. Realistically, that's not how it's going to be done, but rather through testing (either running a test suite, manual tests, or even running it in production and seeing deprecation warnings in the log, for which you'd have years to fix). I don't see application audits being invoked for this, not by a long shot. When I say you need to worry about them a lot less - I mean that you can get 90%+ of the benefits of strict mode, for ALL of your code, with a tiny fraction of the hassle. >From past posts, it's very clear you believe that large projects would gradually migrate to being strict across the board. If we compared the efforts involved in both cases, clearly, the amount of effort with coercive is a lot smaller - as you let the language do most of the work for you. In the few cases where it might be overzealous - it'll alert you to it, and you can easily fix it. In the strict case, yes, you would pretty much have to audit your entire app. Yes, you can do it gradually file by file over the course of a few years - but the combined cost is a lot higher, there would be a lot more code changes and the resulting code - in all likelihood - hiding more bugs due to a lot more explicit casting. > >> Passing boolean(false) where an integer is expected will generate an > >> error. > >> This is a common practice, specifically around internal functions. > >> Example: > >> > https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9f > >> e8916859a07430b94cf42/src/Util/ErrorHandler.php#L58 > > > > It's actually not nearly as common as one might think, and arguably - > > it's may be hiding bug or at least some misunderstanding about the > > semantics of the argument (not always, but sometimes). Warning about > > it (as deprecated) makes perfect sense. I'm going to send some data > > from real world apps later today or early tomorrow. Spoiler - not a > > lot of breakage at all, and coercive rules seem to have a remarkably > > good > signal to noise ratio. > > If Symfony or PHPUnit didn't error in these cases in more than one place, > I'd > be inclined to agree with you (about not being as common as one might > think). But considering two of the best architected and tested > applications in > the ecosystem both error in non-trivial amounts, I think it's fair to > say... I think that once we see some more conclusive test results from these projects, that go slightly deeper than just running the code and seeing deprecation warnings - a lot more people would be inclined to agree. Perhaps even you :) What constitutes major breakage in your mind, for a project as large as PHPUnit, that's acceptable to fix over the course of several years? 20 issues? 100? 200? 500? More? What if many of these issues are actually pointing out potential real world problems, and changing them would result in better more robust code? > >> The difference is with the dual-mode RFC you can choose not to have > >> to cast and keep everything as-is today (or more specifically, you > >> need to explicitly choose strict mode). And you can have user-land > >> behave identically to internals **in both cases**. > > > > Put another way, coercive gets to keep a single, sensible conversion > > rule-set in PHP - with relatively minor updates needed over the course > > of several years. And contrary to what might be implied here, it > > would require a LOT less casting - while still taking advantage of > > much better data sanitation. > > I think you're REALLY downplaying the level of effort that's required for > the > updates you're requiring users make. And that scares me. Given that I actually ran Magento, Drupal, WordPress and both the Symfony and ZF2 skeleton apps with the new coercive ruleset, and I already know there's no reason at all to be scared. More on that later today or early tomorrow - running more tests. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
> -Original Message- > From: Mike Willbanks [mailto:pen...@gmail.com] > Sent: Thursday, February 26, 2015 9:46 PM > To: Anthony Ferrara > Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Anthony, > > > On Thu, Feb 26, 2015 at 1:29 PM, Anthony Ferrara > wrote: > > > Mike, > > One point of clarification: > > > This is true, however, the types that you are receiving back form a > > multitude of data sources might be in a mixed format (databases > for example > > often provide representation back as a string, non-json based web > services > > provide mainly as a string, etc). While I know what my data looks > like > > and I know I am always going to get a "string" integer back I do not > want > > to have to type cast this each and every time. Or that I have a > boolean > > integer representation that is in a string... You get the point. > Sure, > I > > could certainly go in and take 5 minutes and cast each one but I'm > not > > certain why the purpose is there... It specifically changes the > > determination that PHP is a weakly typed language and all of a > sudden I now > > need to care that my string integer boolean is not actually a > boolean. > > It's funny that you bring up boolean... > > With the current coercive proposal, you will still need to worry about > the types: https://wiki.php.net/rfc/coercive_sth#coercion_rules > > > For some unbeknown reason I was inside of my head going ok, i have a > string > integer so that would make an integer and then it would make a boolean. > Thank you for pointing out my obvious miss there :) > > > > > Passing boolean(false) where an integer is expected will generate an > error. This is a common practice, specifically around internal > functions. Example: > https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4ee > ea5fd9fe8916859a07430b94cf42/src/Util/ErrorHandler.php#L58 > > So yes, you'll still need to go in and cast each one **in both RFCs** > (or handle the errors properly). > > > > This is certainly a common case, actually quite often for database > purposes > do we need to handle booleans to integer conversions which my integer > comes back as a string (depending on which extension of course) and which > type field it is. Can you explain that in a bit more detail? What's the data flow exactly, in both directions? Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 26, 2015 10:24 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Zeev, > > > > When I say you need to worry about them a lot less - I mean that you > > can get 90%+ of the benefits of strict mode, for ALL of your code, > > with a tiny fraction of the hassle. > > From past posts, it's very clear you believe that large projects would > > gradually migrate to being strict across the board. If we compared > > the > > Well then, you've heard things I've never said. I'm referring to this: > A few hundred LOC script would likely never enable strict mode, and would > be just fine because of it (you can mentally keep a few hundred LOC in > your head at one time). > > The larger the project, the more the contributors, the more the benefits > to using strict mode. That's not to say that large projects would > immediately go full strict. It's just pointing out that the tradeoffs > would need to be weighed by the authors. The way I read it, "not immediately going full strict" implied they'd gradually go full strict, as opposed to not at all (in which case saying "That's not to say that large projects will necessarily want to go full strict " would have perhaps been more appropriate). Apologies if I misunderstood you. > > Given that I actually ran Magento, Drupal, WordPress and both the > > Symfony and ZF2 skeleton apps with the new coercive ruleset, and I > > already know there's no reason at all to be scared. More on that > > later today or early tomorrow - running more tests. > > They run without triggering E_DEPRECATED errors? Because that means they > will break with 8 (which by your own words is closer to 2-3 years out than > 9- > 10). Not without, but at least in my testing so far - the things that are picked up by the coercive rule-set are quite precise and have excellent signal to noise ratio. We're still working on the patch so I don't want to provide the results just yet because they might be bogus, but I'll share them as soon as they're stable. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
> -Original Message- > From: Mike Willbanks [mailto:pen...@gmail.com] > Sent: Thursday, February 26, 2015 10:43 PM > To: Zeev Suraski > Cc: PHP Internals > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Here is the most basic example and something that people are going to > often > run into. You see this type of code with hydrators, mappers, etc. > Ultimately > the end result is going to be the same: > > https://gist.github.com/mwillbanks/04e3be68f737c25984ab > > I'm not certain if there is a need to explain that bit a bit more. But a > string > "1" as a bool should work as with a string "0". For instance, today we > have > the following for both string's 0 and 1: > > $bool = "0"; > > var_dump($bool); // "0"" > > var_dump($bool == false); // true > var_dump($bool == true); // false > var_dump($bool == 0); // true > var_dump($bool == 1); // false OK, so essentially you're saying that you expect "1" and "0" to be coerced into booleans. This is something we've been wondering about in the Coercive RFC, and in the original version we allowed all scalars to be coerced into bool - but not the other way around. Right now the RFC only allows for integer->bool coercion, but the database use case seems to be a pretty strong one. The options we considered were int only, int+string or none at all. Float is the one that really stands out as pretty meaningless. I think the opposite side is a lot trickier - converting from bool into string (or any other scalar type for that matter) is quite likely to hide bugs. We've found a bunch of bugs like that today, where return values of strpos() are fed without validation into other APIs that expect an offset, and similar use cases. Such code patterns are bound to be hiding bugs, at least in some cases. I'm guessing that direction is less of an issue in your mind, correct? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] A different user perspective on scalar type declarations
> Yes, the database use case and exterior data has been my main concern over > the type hint proposals. Now, this could also be changed (fixed, etc) on > a > different layer (aka database extensions to deal with native types) but > that is > likely far more to bite off than one would want at this point. It is > relatively > painless to go in and cast all of those types but the amount of code out > there > which people are going to just 'expect' this to work will be fairly large > and > one of those cases that will possibly be cause for migration concerns. Thanks a lot for the input! We'll reconsider accepting "1"/"0" as valid Booleans as the original proposal did. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Coercive STH - some real world tests and updated RFC
All,
We've been working in the last few days to test and tune the Coercive STH
patch. I think the results are quite nice, and surprisingly better than
one might have expected.
Before diving into the results, we did update the RFC
(wiki.php.net/rfc/coercive_sth) - with the most notable difference being
allowing NULL->scalar conversions, for two reasons - it's not uncommon for
code to use 'null' as a way to denote an empty optional parameter to for
internal functions, and many internal functions seem to rely on that
behavior themselves. It should be possible to alter this behavior in the
future by changing the internal functions to explicitly handle NULL inputs
as 'please use the default value' - but it's outside the scope of the RFC.
In addition, coercion from scalar to boolean is now limited only to
integer - which seems to be the most popular use case; Beforehand,
coercion was also allowed from float and string - but based on feedback
from Mike, we're reconsidering accepting strings again.
Another change being considered and not yet in the RFC is re-allowing
leading and trailing spaces for numeric strings (sorry Paddy.)
Now to the tests we ran. The goal was to see what kind of effect the
changes to the internal function APIs had on real world apps with large
codebase. The test methodology was done by placing a debugger breakpoint
on zend_error, to ensure no error gets lost in the ether of settings or
callbacks. Here are the results:
Drupal homepage: One new E_DEPRECATED warning, which seems to catch a
real bug, or at least faulty looking code:
$path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean
false.
return $path;
Drupal admin interface (across the all pages): One new E_DEPRECATED
warning, which again seems to catch a real bug - stripslsahes() operating
on a boolean.
Magento homepage (w/ Magento's huge sample DB): One new E_DEPRECATED
warning, again, seems to be catching a real bug of 'false' being fed as
argument 1 of in json_decode() - which is expecting a string full of json
there.
WordPress homepage: One new E_DEPRECATED warning, again, seems to be
catching a real bug of 'false' being fed as argument 1 of substr().
Zend Framework 2 skeleton app: Zero new E_DEPRECATED warnings.
Symfony ACME app: Zero new E_DEPRECATED warnings (across the app).
As I'm sure you know, the above tests invoke a huge number of lines of
code in total, handling filesystem ops, database ops and all sorts of
other things. This is much of the mini test suite that we use to test
PHP's performance and compatibility (e.g. phpng, now PHP 7). So while
this isn't proof that code in the wild isn't going to have more issues -
it's a pretty good initial indication regarding the level of 'breakage' we
can expect. I'm putting breakage in quotes, as people would have several
years to fix these few issues, before the E_DEPRECATED becomes an error
(or an exception, if the engine exceptions RFC passes).
In terms of the test suite (.phpts), the changes cause approximately 700
extra tests to fail out of 13,700, in comparison to w/o the patch.
However, even though I didn't have a chance to go over all of them, it
seems that the vast majority of the failed tests are tests that were
intentionally designed to cover the exact parameter passing behavior,
rather than real likely real world code pieces. A huge number of the
internal functions have this in their test suites:
$variation = array(
'float 10.5' => 10.5,
'float -10.5' => -10.5,
'float 12.3456789000e10' => 12.3456789000e10,
'float -12.3456789000e10' => -12.3456789000e10,
'float .5' => .5,
);
foreach ( $variation as $var ) {
var_dump(readgzfile( $filename, $var ) );
}
Which clearly isn't a very likely input to the size argument of
readgzfile(). All of these now trigger E_DEPRECATED warnings since we no
longer allow float->int conversions if there's no data loss. For some
reason (perhaps a good one, not sure), we have virtually identical pieces
of code for dozens if not hundreds of internal functions that expect
integers - and these types of failures account for the (looks like vast)
majority of phpt failures. Quoting Andrea from a couple of days ago on
this very topic, "to be fair, most of PHP's test suite basically just
tests zpp's behavior", which appears to be absolutely true. The
real-world app tests are probably a much better indicator of the kind of
behaviors our users are going to see than our test suite is.
The takeaway from this seems to be that the approach of tightening the
existing rule-set and applying it to both internal functions and new
user-land code is viable, and does not cause the sky to come down falling.
Preliminary tests suggest it actually finds real potential problems.
More tomorrow.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Coercive STH - some real world tests and updated RFC
> with the most notable difference being > allowing NULL->scalar conversions Forgot to clarify - this is only for calls to internal functions. Userland type hints don't accept NULL->scalar conversions. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
> How many deprecations do you get running the ZF2 and Symfony testsuites? None, but it may have to do with the fact I haven't run them yet :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
> - PHPUnit passes a boolean false to `debug_backtrace()`... which is > documented > as expecting an integer! (There are actually several constant values it > accepts, all of which are integer values.) In this case, PHPUnit is > relying > on the fact that the engine casts booleans to the integers 0 and 1. > (Zeev has > written to the list already indicating that this coercion path will be > supported in the patch.) Matthew, I just wanted to point out that actually, supporting boolean->int coercion is not planned. Converting boolean to integer is actually a very likely scenario where you'd have an outcome that you didn't expect. It's debatable whether sending false to a bitmask is OK or not, but given it's a bitmask, an explicit 0 is a lot more correct. > - PHPUnit is passing the results of $reflector->getDocComment() blindly to > substr() and preg_match*(). getDocComment() is documented as returning > EITHER > a string OR boolean false. Again, PHPUnit is relying on PHP to cast > boolean > false to an empty string. (Zeev has also indicated this coercion path > may be > re-introduced.) We're looking to re-introduce string->boolean (which will likely be common in database scenarios), but not the other way around - where it's very likely hiding a bug. Virtually all of the boolean->string coercions that were flagged as deprecated by the patch were at the very least suspects of being real world bugs. Thanks! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
> -Original Message- > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > Sent: Friday, February 27, 2015 1:19 PM > To: Dmitry Stogov > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > > > On Fri, Feb 27, 2015 at 9:44 AM, Dmitry Stogov wrote: > > > I've added the link to the patch > > https://github.com/php/php-src/pull/1125/files > > > Thanks! > > First, the necessary PHPUnit changes (dev-master) to avoid errors: > > https://gist.github.com/beberlei/8a33ae940829f1186da2 > > > - Doctrine DBAL testsuite: 8 failures > - Doctrine ORM: Crashes unrelated after half the tests, but has about > 30-50% > failures like Symfony2 > - Symfony2 Testsuite: 6215 failures > - Twig: Tests: 1108, Assertions: 1616, Errors: 125. Thanks for the tests! We'll look into those. > Now probably many of the failures are related to few code paths that need > fixing, however I have to find out that and will be a lot of work. But > this is the > good PHP code! Judging by the fact WordPress, Magento and Drupal appear a lot cleaner - you have to wonder..? :) But on a more serious note, I don't think we should assume just about anything from the test suite as reflecting on real world app behavior. I'm not familiar with the Symfony test suite (yet), but I do know that the Symfony skeleton app ran cleanly without a single warning. Is it possible it's testing a lot of things with garbage input, as you would in unit tests, as the our own PHP test suite does? Those account for most of the failures. Also take into account that a project with that many tests (and specifically, failures) is probably not going to have just one or two people responsible for it, but more. It's not that you personally would have to fix Symfony, there are at least a dozen if not dozen people that would help out. > For untested or older PHP code (and yes there is alot out there) i now > have to > collect the errors in production to find all the occurances. This is > nothing i > can just do whenever I want, I need a process to collect and fix this over > time. Now every company needs this process for every project they have out > there. I wish that were true, but in reality, migration is painfully slow and judging by the numbers, doesn't happen - more often than happening. The 'good' companies have ~5yrs after PHP 7 comes out and before PHP 7.x will no longer be supported (and that's according to my hope for a fast PHP 8 timeline; it may be longer as you suggested). Would all projects migrate by that timeline? Let's make a simpler question - would all projects migrate to PHP 7 by 2017, the year 5.6 theoretically stops being supported? We all know the answer to that. The good companies, the security conscious ones that do keep up with new versions, will likely be willing to invest the effort of fixing the code (or hiring someone to do it for them), especially as it'll help them make their apps more robust/secure. And especially as - at least so far - it seems that real world apps have not even a handful of issues per page. All that said, I think we must understand the huge gap between the very high degree of test failures you're seeing in test suites, and the almost none we're seeing in real world apps. If it's similar to the PHP test suite, it's a non-issue, and even if it would take some work to fix the unit tests, it's well worth it. If it's legit, but as you're guessing, may just be several common paths of code that will do away with most of the failures - it's still worth it. Investing several days over the course of several years is great ROI for the value it brings. If, however, the test suite does find a multitude of many different issues - it may bring me to reconsider the RFC, as I told Anthony a few days ago - especially if the signal to noise ratio would be bad. After the results we've seen with real world apps I find it hard to believe, but it's certainly a possible scenario. At the end of the day, it boils down to how much real work do we think will be required to update real world apps out there. Let's also not set unreasonable bars for this change compared to other compatibility breakages we've done (and are stil doing) over the years - again, most of which didn't bring any tangible value to developers (which this change does, a lot). > And the typical agency has hundrets/thousands of drupal, typo3, > wordpress installations out there Correct, but would you have to patch each one separately? You'd have to install updated core for Drupal, Typo3, WP - which you commonly have to do anyway if you care about security. Then there'd be some work to get your common custom modules th
RE: [PHP-DEV] Re: Zend JIT Open Sourced
> -Original Message- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Friday, February 27, 2015 7:31 PM > To: Anthony Ferrara > Cc: Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > On Fri, Feb 27, 2015 at 7:30 PM, Anthony Ferrara > wrote: > > > Dmitry, > > > > > > > It's not a single request cycle. JIT integrated into opcache, it > > > compiles php script(s) of first access and stores code in shared > > > memory. > > > On following requests precompiled code is executed directly from > > > shared memory. > > > > > > - The first request may be extremely slow (few minutes) > > > > That sounds more along the lines of AOT like I did with Recki rather > > than a true JIT (which compiles when a function is called). > > > > Judging from the jit_init() function, it appears like you're compiling > > the entire codebase ahead of time. > > > > Is that correct? > > > > Right now it compiles script (php file) at once. > So yes, our JIT uses some kind of AOT approach, but completely > transparently for the rest of PHP. Just to slightly further clarify - we don't compile the whole codebase at once, but we keep the existing semantics that every file is independent, may change independently of other files, and include() may end up load one file in one flow and another one in another flow. There's isn't any cross-file optimization. > We also tried few different approaches to collect formation about hot > functions and generate code only for them. > Unfortunately, this didn't change the picture. (again, the picture being no performance gains in common Web apps). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Zend JIT Open Sourced
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 27, 2015 10:21 PM > To: Dmitry Stogov > Cc: Zeev Suraski; Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > Dmitry, > > > Sneaky sneaky. Also completely fake. > > It's been brought to my attention that some people have taken what I said > completely out of context and insinuated it as a direct insult to you. Anthony, I'm not sure how calling what Dmitry did sneaky (adj. furtive, stealthy; deceptive, deceitful) and fake (ajd. counterfeit, false) is not an insult. You could have picked wrong, problematic, inadequate, poor - or a dozen other adjectives that don't literally claim that Dmitry did it intentionally to give an unfair advantage to the PHP implementation (which, just in case anybody's wondering, you also wrote literally, using the word 'intentionally' in the previous sentence. You're not clairvoyant and you have no idea whether Dmitry did it intentionally or not, and the adjectives you used mean negative intent. If you apologize, apologize for real and not with disclaimers that it was taken out of context. It wasn't. And I have no idea why I had to bring it to your attention. If somehow you slipped, you should have fixed it yourself immediately. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Zend JIT Open Sourced
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 27, 2015 9:36 PM > To: Dmitry Stogov > Cc: Zeev Suraski; Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > And looking at the code, I can see why. The PHP version is writing to an > internal buffer, while every other version has to write to STDOUT on every > single iteration. Except stdout is buffered too (www.turnkeylinux.org/blog/unix-buffering). Perhaps there's some difference there, but it's not nearly as obvious as you claim (let alone the other stuff in the other email, but let's leave that aside). Personally, my money would be on glibc stdout's buffering being more efficient than our output buffering layer. But you're welcome to test. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Zend JIT Open Sourced
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 27, 2015 10:54 PM > To: Zeev Suraski > Cc: Dmitry Stogov; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > Zeev, > > On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski wrote: > >> -Original Message- > >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] > >> Sent: Friday, February 27, 2015 10:21 PM > >> To: Dmitry Stogov > >> Cc: Zeev Suraski; Jordi Boggiano; PHP Internals > >> Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > >> > >> Dmitry, > >> > >> > Sneaky sneaky. Also completely fake. > >> > >> It's been brought to my attention that some people have taken what I > >> said completely out of context and insinuated it as a direct insult to > >> you. > > > > Anthony, > > > > I'm not sure how calling what Dmitry did sneaky (adj. furtive, > > stealthy; deceptive, deceitful) and fake (ajd. counterfeit, false) is > > not an > insult. > > You could have picked wrong, problematic, inadequate, poor - or a > > dozen other adjectives that don't literally claim that Dmitry did it > > intentionally to give an unfair advantage to the PHP implementation > > (which, just in case anybody's wondering, you also wrote literally, > > using the word 'intentionally' in the previous sentence. > > > > You're not clairvoyant and you have no idea whether Dmitry did it > > intentionally or not, and the adjectives you used mean negative intent. > > > > If you apologize, apologize for real and not with disclaimers that it > > was taken out of context. It wasn't. > > > > And I have no idea why I had to bring it to your attention. If > > somehow you slipped, you should have fixed it yourself immediately. > > I had intended it as a remark about the code. Not about him personally I read the email again and again, and I don't see any possibility to read what you wrote in any other way other than blaming the code author (Dmitry) for being sneaky and intentionally faking the test. Sneaky code would either be code that performs something very different from what one would expect (that's not our case here), or code that was written by the author with the intent of doing something sneaky. >, not about you, not about Zend. I'm not sure why it even needs to be brought up, this has nothing to do with anybody but Dmitry. Which made it worse in my book, as he's is one of the most honest people I've ever bumped into. > PS: Dmitry accepted my apology. Can you please? Yes. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
> -Original Message- > From: Thomas Punt [mailto:tp...@hotmail.co.uk] > Sent: Sunday, March 01, 2015 4:03 PM > To: Zeev Suraski; PHP internals > Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > Hey Zeev, > > > Another change being considered and not yet in the RFC is re-allowing > > leading and trailing spaces for numeric strings (sorry Paddy.) > > I think that rejecting leading and trailing spaces for stringy ints is for the best. > If I only want to accept an integer (in either int or string form), then by > enabling spaces in that input, it would destroy the overall usability of it. > > One scenario I have in mind for this is validating $_GET information for a > RESTful web service. Having potentially an infinite number of URIs that all > point to the same resource isn't good: > > /users/1 > /users/%201 > /users/1%20 > /users/%201%20 > /users/%201%20%20 > etc. > > In this case, I don't want to accept any leading or trailing spaces for the user > ID. So I would therefore not be able to use an `int` type hint because its > acceptance rules would be too lax. > > If spaces are not accepted in stringy ints, and I want to pass a stringy int that > may have leading or trailing spaces in it, then I know I can simply apply a > trim() to it before passing it into a function that's expecting only an int. This > way, the usability of integer-only inputs (as string or ints) isn't compromised > by the rules being too weak. Tom, First of all thanks for the feedback! I think that with leading/trailing spaces we could go either way. It boils down to the question of whether we want spaces to be explicitly trim()'d and have the rule-set more restrictive, or have the rule-set more permissive - preventing some use cases from using it and having to do manual validation instead. Based on the fact this has been a source of back & forth changes (twitter.com/AndreaFaulds/status/570979956349665281), there's not going to be a one size fits all rule-set here. I think that the use cases where it will be harmless to ignore leading/trailing spaces would be more common than those where it's risky or undesired... > > The takeaway from this seems to be that the approach of tightening the > > existing rule-set and applying it to both internal functions and new > > user-land code is viable, and does not cause the sky to come down falling. > > Preliminary tests suggest it actually finds real potential problems. > > > > More tomorrow. > > Overall, a big +1 on this though! The type coercion rules at the moment are > far too lax to be considered useful in most situations IMO. Thanks for the feedback! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
> -Original Message- > From: Lester Caine [mailto:les...@lsces.co.uk] > Sent: Monday, March 02, 2015 11:31 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > Andrea's post highlights the fact that we did try a fix when PHP5 came > out. > What it fails to add is perhaps why the change was reverted? Still today > there > are people pressuring to have it restored? As this thread has shown. At > the > end of the day, this fine tuning of casting action has very little to do > with the > type hinting debate? Now IS the time to discuss the rules but not as part > of > some other RFC? It deserves it's own independent discussion as it SHOULD > apply what ever happens over type hinting. The whole discussion is presently limited to the area of type hints, and this is unlikely to change for 7.0. I think it's good to think about post 7.0 changes - perhaps bringing the rule-set to other areas of PHP (namely implicit casting), but no, it's not the time to seriously discuss this IMHO. > Thomas's example in my book is where a number of things come into play? > My first thought would be just where is this actually processed and so > where > is it trimmed? Additionally how about '001'? However it does highlight > that a > single 'int' hint is not going to satisfy everybody anyway? The thing > perhaps > to point out here is that we are looking in this case at a source that may > well > be using unicode and wonder if THAT may not be more of a problem here? Whether we have weak, strict, coercive or yellow-red type hints added to PHP, they're absolutely not supposed to satisfy everyone. They're supposed to satisfy most use cases, but not all - for the remaining X percent, you'd have to write a bit of custom code, which is fine (either do away with the hint and do custom validation, or use the hint - but do a bit of preprocessing in the calling code). It's not as if everything we deal with in scalars is going to fit into the various scalar type hint buckets anyway. Functions that accept URLs, or emails, or other types of scalar-but-specifically-formatted data have to be validated with custom code anyway. It's fine for other cases to require a bit of custom validation - as long as the key use cases are covered. I'm obviously biased but I believe that the coercive rules actually cover a lot more ground than the weak+strict sets. In other words, with weak+strict, overall, you're going to have to add custom code in a lot more cases than with the coercive rule set (either because weak is too weak and strict will very frequently be too strict, while coercive provides a rule-set that accepts sensible values and reject non-sensible ones, making it work out of the box in most cases). But even with coercive, it's definitely not a one size fits all solution, and it's not supposed to be either. You still have custom code available to you. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
> -Original Message- > From: Lester Caine [mailto:les...@lsces.co.uk] > Sent: Monday, March 02, 2015 12:10 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > On 02/03/15 09:47, Zeev Suraski wrote: > > I'm obviously biased but I believe that the coercive rules actually > > cover a lot more ground than the weak+strict sets. In other words, > > with > > weak+strict, overall, you're going to have to add custom code in a lot > > weak+more > > cases than with the coercive rule set (either because weak is too weak > > and strict will very frequently be too strict, while coercive provides > > a rule-set that accepts sensible values and reject non-sensible ones, > > making it work out of the box in most cases). But even with coercive, > > it's definitely not a one size fits all solution, and it's not > > supposed to be either. You still have custom code available to you. > > But since the horse is now out of the stable, we have to live with strict > anyway, so where will coercive rules fit in if they get accepted as well? > All of > this is just creating different rules for sub-sets of users :( As Anthony proposed if both pass, we're going to have a vote to decide between them, as they do contradict each other. Note that we're not going to know the status of either vote with certainty until March 13th. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question/comment about the Array to String conversion RFC
All, https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates from our guidelines of deprecating features first, and removing them later; It’s addressed in the RFC – but I’m a bit worried that this opens the door to jumping from any sort of notice/warning into errors or removed features without any deprecation phase. In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through E_DEPRECATED. Should we not go through this deprecation cycle, even if may feel anxious to get rid of this behavior? Zeev
