# [VOTE] Scalar Type Hints - Thread: https://externals.io/message/81961 - Original archive: https://news-web.php.net/php.internals/81961 - Started by Andrea Faulds on 2015-02-05T20:14:48+00:00 - Messages: 169 - Page 1 of 7: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/81961.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #81961 — Andrea Faulds — 2015-02-05T20:14:48+00:00 URL: https://externals.io/message/81961#81961 Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Thank you for your time. -- Andrea Faulds http://ajf.me/ --- ## #81975 — Andi Gutmans — 2015-02-05T23:22:26+00:00 URL: https://externals.io/message/81961#81975 · In reply to: #81961 I have to say I’m pretty disappointed at the opening of the vote. We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it. This has now been morphed into something very hard to swallow and IMO having such a declare(…) syntax will be ridiculed by the broader app dev community until the end of time… But even that syntax aside (it’s only syntax after all), I think we lost the ability to reach consensus on something so important to everyone which we haven’t been able to come to agreement on for over 10 years. Finally it was there, in reach and you made a 180 degree turn. I think it’d be so much easier for us to implement weak type hinting. Have everyone rally around it. Be happy and then learn and see whether an additional mechanism is really necessary. We could even add an E_STRICT_TYPES error_reporting flag to help folks “debug” their code if they so wish to see if there are any hotspots in their code they may want to take a look at - again not necessarily an error but maybe a debugging tool. But net, net - why not just implement the thing everyone can agree on. Have something really good in the spirit of the PHP Language for PHP 7 and learn how people leverage that… The reality is that for the majority of the Web community “1” coming in from HTTP should be accepted as a 1. Period. I voted “no” but I will vote “yes” for the competing RFC which is 80% of your RFC. Why are we not given that option?????? Andi > > > Good evening, > > At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. > > I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. > > I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). > > Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. > > The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints > > Thank you for your time. > > -- > Andrea Faulds > http://ajf.me/ --- ## #81976 — Dan Ackroyd — 2015-02-05T23:41:48+00:00 URL: https://externals.io/message/81961#81976 · In reply to: #81961 As much as I want scalar types I'm voting no as: i) Having this code: function foo(int $numberOfRightTurns) { $x = $numberOfRightTurns * 90; return sin(deg2rad($x)) } work or blow up depending on a setting at the top of the file is horrible. ii) Having the code that I write in userland behave differently depending on how people call it, is also horrible. Additionally Andrea, I am disappointed that you opened voting without a option with the 'declare' stuff removed. This is despite myself having asked you for an vote option for just strict types directly several times. Other people have asked for a vote option that allows strict and weak types with a different syntax. I realise that the RFC as it stands is your preferred option, but just not accepting feedback during an RFC is not appropriate. I think it's clear that a lot of people want scalar types, so I hope that we can get the implementation right, but this RFC isn't it. cheers Dan > Good evening, > > At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. > > I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. > > I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). > > Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. > > The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints > > Thank you for your time. > > -- > Andrea Faulds > http://ajf.me/ --- ## #81977 — Thomas Bley — 2015-02-05T23:44:32+00:00 URL: https://externals.io/message/81961#81977 · In reply to: #81975 I think the consensus is not so far away. As far as I understand the rules, it is possible to vote yes and put up a new RFC to remove strict-declare after the voting ends? Regards Thomas Andi Gutmans wrote on 06.02.2015 00:22: > I have to say I’m pretty disappointed at the opening of the vote. > We had a pretty good RFC (thank you) for weak type hinting which was aligned > with the spirit of PHP and everyone was able to rally around it. > This has now been morphed into something very hard to swallow and IMO having > such a declare(…) syntax will be ridiculed by the broader app dev community > until the end of time… But even that syntax aside (it’s only syntax after > all), I think we lost the ability to reach consensus on something so important > to everyone which we haven’t been able to come to agreement on for over 10 > years. Finally it was there, in reach and you made a 180 degree turn. > > I think it’d be so much easier for us to implement weak type hinting. Have > everyone rally around it. Be happy and then learn and see whether an additional > mechanism is really necessary. We could even add an E_STRICT_TYPES > error_reporting flag to help folks “debug” their code if they so wish to > see if there are any hotspots in their code they may want to take a look at - > again not necessarily an error but maybe a debugging tool. > > But net, net - why not just implement the thing everyone can agree on. Have > something really good in the spirit of the PHP Language for PHP 7 and learn how > people leverage that… The reality is that for the majority of the Web > community “1” coming in from HTTP should be accepted as a 1. Period. > > I voted “no” but I will vote “yes” for the competing RFC which is 80% > of your RFC. Why are we not given that option?????? > > Andi > > > > […] --- ## #81979 — Andrea Faulds — 2015-02-05T23:47:49+00:00 URL: https://externals.io/message/81961#81979 · In reply to: #81975 Hi Andi, > > > I have to say I’m pretty disappointed at the opening of the vote. > We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it. This is far from true. Some people on internals were happy, but only some, and everywhere outside internals I looked, the reception was far more negative. > This has now been morphed into something very hard to swallow and IMO having such a declare(…) syntax will be ridiculed by the broader app dev community until the end of time… Nobody mocks Perl or JS for use strict. > But even that syntax aside (it’s only syntax after all), I think we lost the ability to reach consensus on something so important to everyone which we haven’t been able to come to agreement on for over 10 years. Finally it was there, in reach and you made a 180 degree turn. “Consensus” is exaggerated. There was no consensus and to claim there was is to ignore the reality that the PHP community is divided over this issue. I’d love to say that everyone loves weak type hints and if that version had passed we’d all be dancing around happy holding hands, but the reception was not uniformly positive, not even close, and that’s just on internals. > I think it’d be so much easier for us to implement weak type hinting. Have everyone rally around it. Be happy and then learn and see whether an additional mechanism is really necessary. Who’d be happy? I realise you and Zeev are big fans of weak types, as are many others, but there are also a lot of PHP developers who vehemently disagree with you. > We could even add an E_STRICT_TYPES error_reporting flag to help folks “debug” their code if they so wish to see if there are any hotspots in their code they may want to take a look at - again not necessarily an error but maybe a debugging tool. Global error handlers affect all code the interpreter runs, which is why we’ve looked down on them in recent times. > But net, net - why not just implement the thing everyone can agree on. Everyone doesn’t agree on it. If everyone did agree on it, v0.1 of the RFC would have been the one that went to vote. > Have something really good in the spirit of the PHP Language for PHP 7 and learn how people leverage that… The reality is that for the majority of the Web community “1” coming in from HTTP should be accepted as a 1. Period. It’s very well and good you claiming that the “majority” agree, but this does not match my experiences. The PHP community is not a single, homogenous entity. It is very difficult to judge. > I voted “no” but I will vote “yes” for the competing RFC which is 80% of your RFC. Why are we not given that option?????? Because I cannot in good conscience push through something in the name of “consensus” which does not even approach it. -- Andrea Faulds http://ajf.me/ --- ## #81980 — Rowan Collins — 2015-02-05T23:49:04+00:00 URL: https://externals.io/message/81961#81980 · In reply to: #81975 >having such a declare(…) syntax will be ridiculed by the broader app >dev community until the end of time… I think that's laying it on a bit thick. It's no worse than Python's "from __future__ import", or JS's 'use strict;' (quotes included). I wish unknown declare directives were ignored, though, because it would make for a great forward-compatibility mechanism. Still, that, like the syntax format, is a decision made many years ago. --- ## #81981 — Andi Gutmans — 2015-02-05T23:50:48+00:00 URL: https://externals.io/message/81961#81981 · In reply to: #81977 I am not sure. I think we need to explicitly vote on a weak type hinting option. Andrea, I think this should be an option in any vote. Right now it feels like the only option to people is the very challenging, non-consensus driving RFC or nothing. I think we have plenty of key folks who would support weak type hinting and frankly, I think that would be a huge win for everyone! If I need to put forward a separate weak type hinting RFC which would heavily plagiarize Andrea's good work then please let me know. Andi > I think the consensus is not so far away. > As far as I understand the rules, it is possible to vote yes and put up a > new RFC to remove strict-declare after the voting ends? > > Regards > Thomas > > Andi Gutmans wrote on 06.02.2015 00:22: > > > […] > aligned > > […] > having > > […] > community > > […] > important > > […] > 10 > > […] > Have > > […] > additional > > […] > at - > > […] > Have > > […] > learn how > > […] > - > > […] > Please > > […] > happy to > > […] > not a > > […] > However, > > […] > see > > […] > would > > […] > nor weak > > […] > type > > […] > userland > > […] > mode > > […] > it > > […] > (see my > > […] > (2015-02-19). > > […] > type > > […] > sake if > > […] --- ## #81982 — Andrea Faulds — 2015-02-05T23:51:29+00:00 URL: https://externals.io/message/81961#81982 · In reply to: #81976 Hi Dan, > > > As much as I want scalar types I'm voting no as: > > i) Having this code: > > function foo(int $numberOfRightTurns) { > $x = $numberOfRightTurns * 90; > return sin(deg2rad($x)) > } > > work or blow up depending on a setting at the top of the file is horrible. From what I’ve seen this is a rather uncommon case. Also, that code only works for some integer values and not others: the strict version is uniformly broken, the weak version is sometimes broken. > ii) Having the code that I write in userland behave differently > depending on how people call it, is also horrible. Your code always behaves identically. > Additionally Andrea, I am disappointed that you opened voting without > a option with the 'declare' stuff removed. This is despite myself > having asked you for an vote option for just strict types directly > several times. Other people have asked for a vote option that allows > strict and weak types with a different syntax. Yes, I realise you and others have asked for such things. I disagree with you there and I don’t think adding strict types to PHP is really a good idea. I’d prefer we have more rather than less consistency between userland and internals. > I realise that the RFC as it stands is your preferred option, but just > not accepting feedback during an RFC is not appropriate. I have listened to feedback. But listening to feedback and agreeing to any and all suggestions are not the same thing. -- Andrea Faulds http://ajf.me/ --- ## #81983 — Andrea Faulds — 2015-02-05T23:53:31+00:00 URL: https://externals.io/message/81961#81983 · In reply to: #81981 Hi Andi, > > > I am not sure. > > I think we need to explicitly vote on a weak type hinting option. > Andrea, I think this should be an option in any vote. Right now it feels like the only option to people is the very challenging, non-consensus driving RFC or nothing. > I think we have plenty of key folks who would support weak type hinting and frankly, I think that would be a huge win for everyone! Yes, *you* think it’s a huge win for everyone. There are plenty who’d disagree. This RFC is a different attempt at consensus. Rather than asserting the dominance of one idea over the other and completely ignoring the segment of the community that believes in a particular approach, it allows using both approaches. It allows choice. It’s radical, sure, but I think trying to accommodate everyone’s use cases (or at least most people’s) is better than covering only one of two. -- Andrea Faulds http://ajf.me/ --- ## #81984 — Andi Gutmans — 2015-02-05T23:57:51+00:00 URL: https://externals.io/message/81961#81984 · In reply to: #81979 The folks who really want all this great strict typing should head over to Oracle.com and download free open-source Java? I hear it's got a lot of strict typing features in it. Only downside is that it'll take them 10x longer to complete their projects. OK sorry. Had to say that :) I realize it's not the same... Andrea, while I don't agree with what you say I accept it. *But* exactly for the reasons you state (the big divide) we should also have a weak type hinting option to vote for in parallel. If you feel morally unable to do that then I can copy your work and just have another RFC running in parallel but I think that would do a disservice to the good work you've done. Andi > Hi Andi, > > > […] > aligned with the spirit of PHP and everyone was able to rally around it. > > This is far from true. Some people on internals were happy, but only some, > and everywhere outside internals I looked, the reception was far more > negative. > > > […] > having such a declare(…) syntax will be ridiculed by the broader app dev > community until the end of time… > > Nobody mocks Perl or JS for use strict. > > > […] > the ability to reach consensus on something so important to everyone which > we haven’t been able to come to agreement on for over 10 years. Finally it > was there, in reach and you made a 180 degree turn. > > “Consensus” is exaggerated. There was no consensus and to claim there was > is to ignore the reality that the PHP community is divided over this issue. > I’d love to say that everyone loves weak type hints and if that version had > passed we’d all be dancing around happy holding hands, but the reception > was not uniformly positive, not even close, and that’s just on internals. > > > […] > Have everyone rally around it. Be happy and then learn and see whether an > additional mechanism is really necessary. > > Who’d be happy? I realise you and Zeev are big fans of weak types, as are > many others, but there are also a lot of PHP developers who vehemently > disagree with you. > > > […] > “debug” their code if they so wish to see if there are any hotspots in > their code they may want to take a look at - again not necessarily an error > but maybe a debugging tool. > > Global error handlers affect all code the interpreter runs, which is why > we’ve looked down on them in recent times. > > > […] > > Everyone doesn’t agree on it. > > If everyone did agree on it, v0.1 of the RFC would have been the one that > went to vote. > > > […] > and learn how people leverage that… The reality is that for the majority of > the Web community “1” coming in from HTTP should be accepted as a 1. Period. > > It’s very well and good you claiming that the “majority” agree, but this > does not match my experiences. The PHP community is not a single, > homogenous entity. It is very difficult to judge. > > > […] > your RFC. Why are we not given that option?????? > > Because I cannot in good conscience push through something in the name of > “consensus” which does not even approach it. > > -- > Andrea Faulds > http://ajf.me/ --- ## #81985 — Andi Gutmans — 2015-02-05T23:58:30+00:00 URL: https://externals.io/message/81961#81985 · In reply to: #81980 OK. But maybe that's why PHP is better than those languages :) On Thu, Feb 5, 2015 at 3:49 PM, Rowan Collins wrote: > > > > […] > > I think that's laying it on a bit thick. It's no worse than Python's "from > __future__ import", or JS's 'use strict;' (quotes included). > > I wish unknown declare directives were ignored, though, because it would > make for a great forward-compatibility mechanism. Still, that, like the > syntax format, is a decision made many years ago. --- ## #81986 — Andrey Andreev — 2015-02-06T00:02:00+00:00 URL: https://externals.io/message/81961#81986 · In reply to: #81982 Hi Andrea, > Hi Dan, > > > […] > > Yes, I realise you and others have asked for such things. I disagree with you there and I don’t think adding strict types to PHP is really a good idea. I’d prefer we have more rather than less consistency between userland and internals. > > > […] > > I have listened to feedback. But listening to feedback and agreeing to any and all suggestions are not the same thing. > It's fine that you disagree. But enabling others to disagree with you via votes would've been more fair. With the available options, it's either your way or no way. Cheers, Andrey. --- ## #81987 — Andi Gutmans — 2015-02-06T00:02:26+00:00 URL: https://externals.io/message/81961#81987 · In reply to: #81983 > Hi Andi, > > > […] > like the only option to people is the very challenging, non-consensus > driving RFC or nothing. > > […] > and frankly, I think that would be a huge win for everyone! > > Yes, *you* think it’s a huge win for everyone. There are plenty who’d > disagree. > > This RFC is a different attempt at consensus. Rather than asserting the > dominance of one idea over the other and completely ignoring the segment of > the community that believes in a particular approach, it allows using both > approaches. It allows choice. It’s radical, sure, but I think trying to > accommodate everyone’s use cases (or at least most people’s) is better than > covering only one of two. > Just to be clear, I think it's a thoughtful RFC. I don't think it's dumb. I can even see where you're coming from on trying to balance the approaches. I do think we should also represent the weak type hinting only folks in a ballot too. Andi --- ## #81989 — Andrea Faulds — 2015-02-06T00:05:31+00:00 URL: https://externals.io/message/81961#81989 · In reply to: #81984 Hi Andi, > > > The folks who really want all this great strict typing should head over to Oracle.com and download free open-source Java? I hear it's got a lot of strict typing features in it. Only downside is that it'll take them 10x longer to complete their projects. OK sorry. Had to say that :) I realize it's not the same… I don’t think it’s terribly funny to tell a large portion of the PHP community to go away. > Andrea, while I don't agree with what you say I accept it. *But* exactly for the reasons you state (the big divide) we should also have a weak type hinting option to vote for in parallel. If you feel morally unable to do that then I can copy your work and just have another RFC running in parallel but I think that would do a disservice to the good work you've done. No, I don’t think that’s fair. I’d be against holding a vote on strict types only for the same reason: the community is divided. Letting one side “win" is simply unfair on everyone else. To quote myself in the Scalar Type Hints thread, here’s a rough tally of who was in favour of what in the v0.1 thread (I think “yourself” was Zeev in that context): > > > Let’s have a look. From a quick skim over the thread for v0.1: > > * In favour of weak types (or the RFC anyway): Adam, Stas, yourself, Jordi, Pierre, > * Against, in favour of strict types: Maxime, Nikita, Markus, Marco, Leigh, Levi, Sven(?) > * In favour of strict types, not against weak types as compromise: Matthew > * Somewhat in favour: Sebastian > * In favour of allowing both approaches: Marcio, Thomas, Marco > > I apologise if I am misrepresenting anyone’s position. > > This is unlikely to be super-representative of the PHP community. However, I’m not sure I’d say “overwhelmingly positive”. It can be easy to get confirmation bias when reading RFC threads. > > It is very clear to me that a lot of people would like strict types, and some people would like weak types. As to their relative numbers, I cannot say. > > I don’t think it’s really fair to cover only the use case of one half of the PHP community. The other half counts too. This is a rather divisive issue. As is rather clear, there was no such consensus on internals. Confirmation bias can be a powerful thing, and it’s easy to forget that the number of messages doesn’t reflect the number of participants. The views on other places were, from my experience, even more against weak types than internals. Internals seems to be the most pro-weak types PHP community I’m a part of. Because of this schism, I really think it would be completely unfair to force through weak types. I know internals might like it (or some of internals, anyway), and I know you and Zeev certainly do, but it’s not as clear-cut in the wider community. This isn’t some minor issue, either: it’s a very frequently resurfacing topic, and one which is particularly divisive. It’s not some minor syntax issue that merely holding a vote will solve. -- Andrea Faulds http://ajf.me/ --- ## #81990 — Andi Gutmans — 2015-02-06T00:24:03+00:00 URL: https://externals.io/message/81961#81990 · In reply to: #81989 > Hi Andi, > > > […] > to Oracle.com and download free open-source Java? I hear it's got a lot of > strict typing features in it. Only downside is that it'll take them 10x > longer to complete their projects. OK sorry. Had to say that :) I realize > it's not the same… > > I don’t think it’s terribly funny to tell a large portion of the PHP > community to go away. > Oh come on... You're taking me a bit too literally. Your proposal isn't Java-like strict typing... I even said that. > > […] > for the reasons you state (the big divide) we should also have a weak type > hinting option to vote for in parallel. If you feel morally unable to do > that then I can copy your work and just have another RFC running in > parallel but I think that would do a disservice to the good work you've > done. > > No, I don’t think that’s fair. I’d be against holding a vote on strict > types only for the same reason: the community is divided. Letting one side > “win" is simply unfair on everyone else. > I don't understand that statement. You mean it's not OK for any side to win unless you win? Or are you saying that you tried to strike a balance between the two parties which you hoped everyone could rally around? What if they can't? It's all or nothing? Btw, not trying to be facetious but really trying to understand where you're coming from. > To quote myself in the Scalar Type Hints thread, here’s a rough tally of > who was in favour of what in the v0.1 thread (I think “yourself” was Zeev > in that context): > Zeev and I aren't twins (thank god for him) and aren't always in agreement on such topics. Looks like I am not on that list. Don't see him either btw... Anyway, I think I need to sleep on it... I understand what you're trying to do. It's definitely not a crazy strict type hinting approach (which would be very bad)... But I find elements of it challenging... Andi > > […] > Jordi, Pierre, > > […] > Leigh, Levi, Sven(?) > > […] > Matthew > > […] > However, I’m not sure I’d say “overwhelmingly positive”. It can be easy to > get confirmation bias when reading RFC threads. > > […] > some people would like weak types. As to their relative numbers, I cannot > say. > > […] > the PHP community. The other half counts too. This is a rather divisive > issue. > > As is rather clear, there was no such consensus on internals. Confirmation > bias can be a powerful thing, and it’s easy to forget that the number of > messages doesn’t reflect the number of participants. > > The views on other places were, from my experience, even more against weak > types than internals. Internals seems to be the most pro-weak types PHP > community I’m a part of. > > Because of this schism, I really think it would be completely unfair to > force through weak types. I know internals might like it (or some of > internals, anyway), and I know you and Zeev certainly do, but it’s not as > clear-cut in the wider community. > > This isn’t some minor issue, either: it’s a very frequently resurfacing > topic, and one which is particularly divisive. It’s not some minor syntax > issue that merely holding a vote will solve. > > -- > Andrea Faulds > http://ajf.me/ --- ## #81991 — Andrea Faulds — 2015-02-06T00:32:58+00:00 URL: https://externals.io/message/81961#81991 · In reply to: #81990 Hi, > > > Oh come on... You're taking me a bit too literally. Your proposal isn't > Java-like strict typing... I even said that. I still disagree with the sentiment, but never mind. I realise it was just a joke. > > […] > > I don't understand that statement. You mean it's not OK for any side to win > unless you win? Or are you saying that you tried to strike a balance > between the two parties which you hoped everyone could rally around? The latter. > What > if they can't? It's all or nothing? Btw, not trying to be facetious but > really trying to understand where you're coming from. I just don’t feel comfortable if only one camp is satisfied. It doesn’t seem fair. While first-past-the-post politics is “winner takes it all” (usually, anyway… but that’s way off topic), the design of the PHP programming language shouldn’t be. Compromise doesn’t lead to ideal solutions, sure, but it does lead to more people being happy than otherwise, if it’s a good compromise. > > […] > > Zeev and I aren't twins (thank god for him) and aren't always in agreement > on such topics. Looks like I am not on that list. Don't see him either > btw… huh? Maybe you misunderstood me. I meant that in that list in the quote, the word “yourself” was referring to Zeev, since that’s who I was responding to in the original email (I think). I don’t think you were in that discussion - maybe you were and I missed you. > Anyway, I think I need to sleep on it... I understand what you're trying to > do. It's definitely not a crazy strict type hinting approach (which would > be very bad)... But I find elements of it challenging… I also have some gripes with this RFC - declare() isn’t the nicest of things to have to type on every file. But, I think it seems to work out better overall than all the numerous other proposals I’ve seen so far, and that’s why I like it. I also need sleep. Goodnight! -- Andrea Faulds http://ajf.me/ --- ## #81992 — Pierre Joye — 2015-02-06T00:50:15+00:00 URL: https://externals.io/message/81961#81992 · In reply to: #81975 > I have to say I’m pretty disappointed at the opening of the vote. > We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it. > This has now been morphed into something very hard to swallow and IMO having such a declare(…) syntax will be ridiculed by the broader app dev community until the end of time… But even that syntax aside (it’s only syntax after all), I think we lost the ability to reach consensus on something so important to everyone which we haven’t been able to come to agreement on for over 10 years. Finally it was there, in reach and you made a 180 degree turn. > I think it’d be so much easier for us to implement weak type hinting. Have everyone rally around it. Be happy and then learn and see whether an additional mechanism is really necessary. We could even add an E_STRICT_TYPES error_reporting flag to help folks “debug” their code if they so wish to see if there are any hotspots in their code they may want to take a look at - again not necessarily an error but maybe a debugging tool. > > But net, net - why not just implement the thing everyone can agree on. Have something really good in the spirit of the PHP Language for PHP 7 and learn how people leverage that… The reality is that for the majority of the Web community “1” coming in from HTTP should be accepted as a 1. Period. > > I voted “no” but I will vote “yes” for the competing RFC which is 80% of your RFC. Why are we not given that option?????? I have to agree here while I like the declare option, it should have been an option as we clearly do not have a consensus during the discussions (and will never have). Jeopardize the whole because of that sounds dangerous to me. --- ## #81993 — Andrea Faulds — 2015-02-06T00:53:25+00:00 URL: https://externals.io/message/81961#81993 · In reply to: #81992 Hi Pierre, > > > I have to agree here while I like the declare option, it should have > been an option as we clearly do not have a consensus during the > discussions (and will never have). Jeopardize the whole because of > that sounds dangerous to me. Three-way votes for this type of issue are rather nightmarish. Originally, this RFC was going to have at least three separate options in the vote, but I gave up on that because of the sheer complexity. Whatever result you’d get wouldn’t be very fair and the margins wouldn’t make sense. If someone wants to make a separate RFC later for strict types or weak types or whatever, nothing would stop them. Thanks. -- Andrea Faulds http://ajf.me/ --- ## #81994 — Adam Harvey — 2015-02-06T01:23:15+00:00 URL: https://externals.io/message/81961#81994 · In reply to: #81961 > At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. True, and I probably won't respond to any replies to this because we don't need more noise, but I do want to explain my -1 vote. This is long and rambling. I apologise. I've posted a formatted version of this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case it's easier to read. In no particular order, my issues with this RFC: ## The declare switch Adding the cognitive overhead for each file for developers to have to remember whether they have to cast a value before passing it to a function or if PHP will automagically do that for them is a bad thing. Of course, in a small, well compartmentalised file, or a single developer code base, it wouldn't be a problem. Unfortunately, a lot of PHP projects aren't that tidy. (Probably most of them, in fact.) I also disagree with the comparisons that have been drawn on Internals between `declare(strict_types=1)`, `use strict`, and `from __future__ import foo` statements. They're not the same thing at all: * `use strict` is ultimately about code quality — am I doing something dumb? * `from __future__ import foo` is ultimately about features — yes, I want to opt-in for the new shiny. * `declare(strict_types=1)` isn't either of those, although it might superficially appear so — what it's really about is "I reject your philosophy and substitute my own" in terms of typing. There are structural decisions we can and should let our users make. I believe this isn't one of them: allowing users to fundamentally change the typing semantics of a language on a module-by-module level is, in my opinion, insanity. Languages have to be opinionated about this sort of issue: if they weren't, there'd only be one programming language and it would have 800 switches to configure before you could write a line of code. This sort of decision is the whole point of designing a language: abdicating it by providing a switch is effectively us shrugging and saying "sure, whatever, we don't care, so now we'll make you care". ## Strong typing This ties into the previous point: for scalars, PHP has never been a strongly typed language. I was once on the train of strict typing being universally better — if you know that you always have an integer, you never have to worry about a bad conversion, right? And, if I was designing a language from scratch, I'd probably still feel that way. That language wouldn't be PHP, though. PHP is unapologetically weakly typed from top to bottom. Designing a feature to break that would be bad enough. Designing a feature to optionally break that is insidious. If you care about whether the zval IS_STRING, you can check that today. Encouraging our users to care goes against the entire philosophy of the language. To be clear: yes, we have problems in our type conversion matrix. The fact that `"21 Jump Street" == 21` is an issue (particularly because it's silent), and we should be talking about that. But strong typing is not the solution. ## Caller versus callee Making the caller responsible for choosing the type behaviour is a clever hack. (No pun intended, Facebookers.) I find the idea intriguing from an academic perspective. Unfortunately, as with the above point, this isn't consistent with PHP as a language that's existed for 20 years and had type hinting in its current form for over 10 years. If we accept this, then we only widen the gap between scalar values and array/object ones: for one set of type declarations, the behaviour is determined entirely by the callee, and for another, it's determined by both the callee (via the type hint) and the caller (whether it will be converted or not). ## So what do we do for 7.0? From where I sit, we had a good solution: it was the 0.1 version of this RFC. It behaved like PHP should behave, respected PHP's long standing scalar type handling and conversion rules, but most importantly, it solved the **actual** problem scalar type hints are supposed to solve in the simplest possible way: Can I guarantee that my function that expects an integer will really get an integer? I don't think that adding complexity on top of that helps anyone in the long run. Yes, we get to tick some extra boxes — "we support strong typing", "we support weak typing", "we put the user in control" — but at the cost of having a language that not only supports, but advertises multiple, inconsistent behaviours, requires users to be aware of conversion minutiae that they shouldn't have to be mindful of, and doesn't do anything to solve the actual problem above. Adam --- ## #82017 — Andi Gutmans — 2015-02-06T06:13:44+00:00 URL: https://externals.io/message/81961#82017 · In reply to: #81994 +1 > > > > > […] > > True, and I probably won't respond to any replies to this because we > don't need more noise, but I do want to explain my -1 vote. This is > long and rambling. I apologise. I've posted a formatted version of > this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case > it's easier to read. > > In no particular order, my issues with this RFC: > > ## The declare switch > > Adding the cognitive overhead for each file for developers to have to > remember whether they have to cast a value before passing it to a > function or if PHP will automagically do that for them is a bad thing. > Of course, in a small, well compartmentalised file, or a single > developer code base, it wouldn't be a problem. Unfortunately, a lot of > PHP projects aren't that tidy. (Probably most of them, in fact.) > > I also disagree with the comparisons that have been drawn on Internals > between `declare(strict_types=1)`, `use strict`, and `from __future__ > import foo` statements. They're not the same thing at all: > > * `use strict` is ultimately about code quality — am I doing something dumb? > * `from __future__ import foo` is ultimately about features — yes, I > want to opt-in for the new shiny. > * `declare(strict_types=1)` isn't either of those, although it might > superficially appear so — what it's really about is "I reject your > philosophy and substitute my own" in terms of typing. > > There are structural decisions we can and should let our users make. I > believe this isn't one of them: allowing users to fundamentally change > the typing semantics of a language on a module-by-module level is, in > my opinion, insanity. Languages have to be opinionated about this sort > of issue: if they weren't, there'd only be one programming language > and it would have 800 switches to configure before you could write a > line of code. This sort of decision is the whole point of designing a > language: abdicating it by providing a switch is effectively us > shrugging and saying "sure, whatever, we don't care, so now we'll make > you care". > > ## Strong typing > > This ties into the previous point: for scalars, PHP has never been a > strongly typed language. I was once on the train of strict typing > being universally better — if you know that you always have an > integer, you never have to worry about a bad conversion, right? And, > if I was designing a language from scratch, I'd probably still feel > that way. > > That language wouldn't be PHP, though. PHP is unapologetically weakly > typed from top to bottom. Designing a feature to break that would be > bad enough. Designing a feature to optionally break that is insidious. > If you care about whether the zval IS_STRING, you can check that > today. Encouraging our users to care goes against the entire > philosophy of the language. > > To be clear: yes, we have problems in our type conversion matrix. The > fact that `"21 Jump Street" == 21` is an issue (particularly because > it's silent), and we should be talking about that. But strong typing > is not the solution. > > ## Caller versus callee > > Making the caller responsible for choosing the type behaviour is a > clever hack. (No pun intended, Facebookers.) I find the idea > intriguing from an academic perspective. Unfortunately, as with the > above point, this isn't consistent with PHP as a language that's > existed for 20 years and had type hinting in its current form for over > 10 years. If we accept this, then we only widen the gap between scalar > values and array/object ones: for one set of type declarations, the > behaviour is determined entirely by the callee, and for another, it's > determined by both the callee (via the type hint) and the caller > (whether it will be converted or not). > > ## So what do we do for 7.0? > > From where I sit, we had a good solution: it was the 0.1 version of > this RFC. It behaved like PHP should behave, respected PHP's long > standing scalar type handling and conversion rules, but most > importantly, it solved the **actual** problem scalar type hints are > supposed to solve in the simplest possible way: > > Can I guarantee that my function that expects an integer will > really get an integer? > > I don't think that adding complexity on top of that helps anyone in > the long run. Yes, we get to tick some extra boxes — "we support > strong typing", "we support weak typing", "we put the user in control" > — but at the cost of having a language that not only supports, but > advertises multiple, inconsistent behaviours, requires users to be > aware of conversion minutiae that they shouldn't have to be mindful > of, and doesn't do anything to solve the actual problem above. > > Adam --- ## #82019 — francois@tekwire.net — 2015-02-06T07:39:08+00:00 URL: https://externals.io/message/81961#82019 · In reply to: #81994 +1 > -----Message d'origine----- > De : adam@adamharvey.name [mailto:adam@adamharvey.name] De la part > de Adam Harvey > Envoyé : vendredi 6 février 2015 02:23 > À : Andrea Faulds > Cc : PHP Internals > Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints > > > > […] > don’t think there needs to be, or will be, much further discussion. > > True, and I probably won't respond to any replies to this because we > don't need more noise, but I do want to explain my -1 vote. This is > long and rambling. I apologise. I've posted a formatted version of > this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case > it's easier to read. > > In no particular order, my issues with this RFC: > > ## The declare switch > > Adding the cognitive overhead for each file for developers to have to > remember whether they have to cast a value before passing it to a > function or if PHP will automagically do that for them is a bad thing. > Of course, in a small, well compartmentalised file, or a single > developer code base, it wouldn't be a problem. Unfortunately, a lot of > PHP projects aren't that tidy. (Probably most of them, in fact.) > > I also disagree with the comparisons that have been drawn on Internals > between `declare(strict_types=1)`, `use strict`, and `from __future__ > import foo` statements. They're not the same thing at all: > > * `use strict` is ultimately about code quality — am I doing something dumb? > * `from __future__ import foo` is ultimately about features — yes, I > want to opt-in for the new shiny. > * `declare(strict_types=1)` isn't either of those, although it might > superficially appear so — what it's really about is "I reject your > philosophy and substitute my own" in terms of typing. > > There are structural decisions we can and should let our users make. I > believe this isn't one of them: allowing users to fundamentally change > the typing semantics of a language on a module-by-module level is, in > my opinion, insanity. Languages have to be opinionated about this sort > of issue: if they weren't, there'd only be one programming language > and it would have 800 switches to configure before you could write a > line of code. This sort of decision is the whole point of designing a > language: abdicating it by providing a switch is effectively us > shrugging and saying "sure, whatever, we don't care, so now we'll make > you care". > > ## Strong typing > > This ties into the previous point: for scalars, PHP has never been a > strongly typed language. I was once on the train of strict typing > being universally better — if you know that you always have an > integer, you never have to worry about a bad conversion, right? And, > if I was designing a language from scratch, I'd probably still feel > that way. > > That language wouldn't be PHP, though. PHP is unapologetically weakly > typed from top to bottom. Designing a feature to break that would be > bad enough. Designing a feature to optionally break that is insidious. > If you care about whether the zval IS_STRING, you can check that > today. Encouraging our users to care goes against the entire > philosophy of the language. > > To be clear: yes, we have problems in our type conversion matrix. The > fact that `"21 Jump Street" == 21` is an issue (particularly because > it's silent), and we should be talking about that. But strong typing > is not the solution. > > ## Caller versus callee > > Making the caller responsible for choosing the type behaviour is a > clever hack. (No pun intended, Facebookers.) I find the idea > intriguing from an academic perspective. Unfortunately, as with the > above point, this isn't consistent with PHP as a language that's > existed for 20 years and had type hinting in its current form for over > 10 years. If we accept this, then we only widen the gap between scalar > values and array/object ones: for one set of type declarations, the > behaviour is determined entirely by the callee, and for another, it's > determined by both the callee (via the type hint) and the caller > (whether it will be converted or not). > > ## So what do we do for 7.0? > > From where I sit, we had a good solution: it was the 0.1 version of > this RFC. It behaved like PHP should behave, respected PHP's long > standing scalar type handling and conversion rules, but most > importantly, it solved the **actual** problem scalar type hints are > supposed to solve in the simplest possible way: > > Can I guarantee that my function that expects an integer will > really get an integer? > > I don't think that adding complexity on top of that helps anyone in > the long run. Yes, we get to tick some extra boxes — "we support > strong typing", "we support weak typing", "we put the user in control" > — but at the cost of having a language that not only supports, but > advertises multiple, inconsistent behaviours, requires users to be > aware of conversion minutiae that they shouldn't have to be mindful > of, and doesn't do anything to solve the actual problem above. > > Adam --- ## #82066 — Nikita Popov — 2015-02-06T20:22:44+00:00 URL: https://externals.io/message/81961#82066 · In reply to: #81961 > Good evening, > > At long last, I’m going to put the RFC to a vote. It’s been long enough - > I don’t think there needs to be, or will be, much further discussion. > > I’d like to make sure that everyone voting understands the RFC fully. > Please read the RFC in full: the details are important. And if anyone has > any questions or uncertainties, please ask them before voting. I am very > happy to answer them. > > I would urge everyone who wants type hints to vote for this RFC. It is not > a perfect solution, but there can be no perfect solution to this issue. > However, I think it is better than most of the alternatives suggested thus > far - see the rationale section, and previous discussions. Crucially, this > RFC would keep PHP a weakly-typed language, and not force either strict > typing, nor weak typing, on anyone who does not want it. It would allow the > addition of type hints to existing codebases. It would not create a > situation where userland functions are strict yet internal functions are > not, because the strict mode affects both. I’ve tested the implementation > myself on my own code, and it worked well, providing benefits other > proposals would not have given (see my previous post about my experiences). > > Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). > In addition to the vote on the main RFC, there is also a vote on the type > aliases issue, and a vote to reserve the type names for future RFCs’ sake > if this RFC fails. > > The RFC can be found here, and it contains a voting widget: > https://wiki.php.net/rfc/scalar_type_hints > > Thank you for your time. > After much initial reluctance, I've voted in favor of this RFC. I'm a proponent of strict scalar typing. I will not explain the reasons behind this here, because they have been covered extensively in the previous threads and I no longer have the patience for such heavily prejudiced discussions. As such this mail is really an explanation why I am voting for an RFC defaulting to weak types, despite my misgivings with such a typing scheme. A primary appeal of this RFC is that the "strict_types" mode not only influences userland function calls, but also calls to internal functions. I really appreciate the symmetry behind this - a plain strict scalar typing proposal would only cover userland calls, while this also enforces proper type usage with internal ones. This seems very reasonable, as the same arguments in favor of strict scalar types for userland functions apply nearly identically to internal functions as well. Another advantage of this approach is that there are fewer interoperability issues between libraries using strict typing internally and external code not making use of it. A pure strict scalar typing proposal would likely cause severe integration issues between code using scalar types and code not using them at all and as such using relatively unpredictable data types. This issue will not be entirely alleviated by this proposal (primarily due to the lack of generic or semi-generic types), but it will be much more limited and libraries should be able to safely use the strict typing mode without alienating users. Lastly, I would like to talk about cognitive overhead. This RFC uses a per-file typing mode declaration and there may be concerns about having to mentally adjust to different modes being used in different files of a project. While I think this is an important concern, there are two ameliorating factors: a) It is very likely that libraries using strict scalar types will use them in the entire project rather than having a mix of different modes in different files. Similarly applications will likely also either be fully strictly typed or have clearly separated front- and backend components where only the latter uses strict scalar types. b) Within one file, this RFC actually removes mental overhead, because type declarations will behave identically for userland and internal functions. You won't have to deal with some functions being liberal and some being strict. Thanks, Nikita --- ## #82068 — Stelian Mocanita — 2015-02-06T20:42:26+00:00 URL: https://externals.io/message/81961#82068 · In reply to: #81984 Sending people who want to have more structure in the language to Java is downright bad, not to mention that it sounds completely dictatorial. I would just put that in the next Zend newsletter to make it clear for your customers that there is a saner option. Stelian > The folks who really want all this great strict typing should head over to > Oracle.com and download free open-source Java? I hear it's got a lot of > strict typing features in it. Only downside is that it'll take them 10x > longer to complete their projects. OK sorry. Had to say that :) I realize > it's not the same... > > Andrea, while I don't agree with what you say I accept it. *But* exactly > for the reasons you state (the big divide) we should also have a weak type > hinting option to vote for in parallel. If you feel morally unable to do > that then I can copy your work and just have another RFC running in > parallel but I think that would do a disservice to the good work you've > done. > > Andi > > > > > > […] > some, > > […] > lost > > […] > which > > […] > it > > […] > issue. > > […] > had > > […] > error > > […] > of > > […] > Period. > > […] > of > > […] --- ## #82069 — Dennis Birkholz — 2015-02-06T21:23:15+00:00 URL: https://externals.io/message/81961#82069 · In reply to: #82066 Am 06.02.2015 um 21:22 schrieb Nikita Popov: > After much initial reluctance, I've voted in favor of this RFC. Thank you Nikita for this decision. I would really like to have any kind of scalar type hints introduced into PHP. I think most want this, but do not agree if and how type conversion should happen. I urge all people who can vote to consider if they can imagine a compromise that satisfies all parties better and if there will ever be scalar type hints in the near future if this vote fails. I am concerned the answers are probably not and no. So please vote in a way that we can have scalar type hints in the near future. Thanks to all of you for participating in this discussion and making PHP a better language! Dennis --- ## #82070 — Andi Gutmans — 2015-02-06T21:31:50+00:00 URL: https://externals.io/message/81961#82070 · In reply to: #82068 > > > Sending people who want to have more structure in the language to Java > is downright bad, not to mention that it psounds completely dictatorial. I > would just put that in the next Zend newsletter to make it clear for your > customers that there is a saner option. > Oh come on. I was kidding. I will remember for next time this list has no sense of humor. And just for the record this is not a zend thing. Four zenders voted based on their own beliefs - three votes were no and one was yes. So diversity here too plus a small minority of total voters who can't really move the needle much. Let's keep the conversation pragmatic. I will try and refrain from any humor. Andi > Stelian > > > […] --- Next page: https://externals.io/message/81961.md?page=2