Re: [PHP-DEV] static constructor
Johannes Ott wrote: I tried to get some RFC karma for my wiki account, following those lines: Email internals@lists.php.net requesting RFC karma for your wiki account. In the email, remind people about the RFC you plan to create. Note that RFC karma does not automatically give you karma to vote. See https://wiki.php.net/rfc/voting#rfc_proposer I didn't get any reaction on my mail for three days, is this normal or have I done something wrong? As far as I can tell (I do not have a @php.net account) everything is fine regarding your request. However, you've requested RFC karma on Friday afternoon (UTC), and it's still weekend for most, so it may take a while to be answered. As I understand it, any new RFC is too late for PHP 7 anyway, so the delay shouldn't be a problem. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
I am aware of this, but unless I just missed it that site doesn't show *when* they got an account. As you already said, there's no acceptation date on that site, but it seems that new accounts are appended to the end of the list - http://people.php.net/?page=33 Probably better than nothing... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A plea for unity on scalar types
On Fri, Mar 13, 2015 at 8:51 PM, Scott Arciszewski sc...@arciszewski.me wrote: Pavel_Kouřil wrote: - It is a setting that changes the language's behavior; I don't think that it matters whether or not it would be an INI setting or the declare() one, because both of them are bad. It allows people who want strict typing to declare it on a per-PHP-file basis. An INI setting cannot offer this guarantee. This is required if weak and strict are to be both supported. - It does not unite different usages of PHP into a single group; it does exactly the opposite, splitting PHP usage into TWO groups. It also allows the two groups to work together rather than forking PHP into separate languages: PHPstrict and PHPweak. - Once this dual mode would be introduced to PHP, there would probably be no way of removing it later without massive BC break, once most people would realize that it is really awful to have it in the language. What is really awful about this? Moving forward, everything could move towards strict typing. I could see PHP 8 or 9 having strict be the default, if everyone wanted that. And then the declare() being deprecated and removed as major versions increase. Scott Hello, I'm sorry, I totally overlooked your email, so I'm replying with a little delay. Sure, per-file is better than ini setting, but better doesn't mean good (because it is still a pretty bad approach). The ini setting at least has the option to be turned off in code once everyone realizes it was a bad idea (register_globals via htaccess, for instance), but PHP would be stuck with the declare for a long time - this is not an easily revertable change, once PHP ships with it. The two groups (people who want strong typing and weak typing) will not work *together* though. And it will be a nightmare for everyone working on multiple projects from mulitple clients or so. PHP will IMHO never be strongly-typed by default. It would break BC so much it's not just possible. The best approach to have some reasonable type rules is to progressively strenghten the rules (as Zeev's RFC tried to do so, but he probably did two steps in one RFC and that's what people dislike about it?). I think that PHP's type system would get to some equilibrium by this - people wanting stronger typing would tried to introduce it and people wanting weaker one would balance it and eventually there could be a point on which both sides could agree on. I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the RFC being good for the userland developers in the long run. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Minimum version of GCC required to build PHP
What is the minimum version of GCC required to build PHP? I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner m...@php.net wrote: On 15 03 2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. I think it does raise a significant question around the voting practices. Something that I think we need to discuss as a group. So consider that discussion open. Jeez, that is becoming ridiculous. So, if you’re that good in counting, how many did not vote before STHv0.3? Is there a way to check when someone got a php.net account/karma? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Basic Scalar Types
Am 14.03.2015 um 00:44 schrieb Zeev Suraski z...@zend.com: Zeev, If I put it into vote until Sunday, we're breaking the voting process. Which required an apt discussion phase which definitely isn't given when we start Sunday. Bob, I do see it differently but obviously very much respect your position. Why do I see it differently? The mandatory two week discussion period is there to avoid a situation where there's not enough time to debate the merit of the proposal, as well as to avoid 'stealth' RFCs where it's over before some people even notice. Both of these elements aren't here. An identical proposal has been debated in depth and from all possible directions? Check. It's perhaps the most watched internals@ topic of all times with zero chance for stealth RFCs? Check. There's not going to be any new meaningful discussion over the next 10 days where something that hasn't already been said will be said. But again, I respect your position. Maybe that was the intention. But if you want that, we'd first need to allow that explicitly in the RFC. If we just all act like that rule doesn't fit my current situation, let's ignore it … why do we then have rules at all? I'd like to consider them as hard rules which we don't break, except a RM requires it. Also. Your timeline RFC leaves a bit room for interpretation (Line up means? Put into discussion? Vote? Have votes all already accepted?) . If necessary, I'll rather push timeline a bit than breaking vote process. Good point. Looks like I shouldn't be writing non-technical RFCs as they're always more than a bit open for interpretation :) Or at least internals@ needs to scrutinize them more. Either way, you're right that technically we could say your RFC is very much 'lined up' right now, before the Mar 15 deadline. While I'd hate to prolong the timeline for a technicality like that, for this specific case I think it's worth it - it's an extremely important topic and we've been dealing with it for almost a decade. Also, the good news is that it's unlikely to delay the 2nd milestone given that we have implementations for all of the different options already. Now, my key concern is that you're saying you'd put it to a vote only if you see both other RFCs are failing. The Dual Mode RFC is hovering above and below passing, and we have no way of knowing how many people who voted in favor of the Dual Mode RFC would actually much rather vote for the Basic one if it was available (we know of at least one, and actually two if you count me - my guess is there are a lot more). What I think makes sense is to do something similar to what I did plan to do with the Coercive STH RFC - put it up to a vote as soon as practical; If we see that it's not passing, withdraw it. I'm very clearly on the record saying that if the Dual Mode RFC remains the only viable alternative (besides not having anything) - I'll not only change my vote to yes, but also encourage everyone else that I can to do the same (which I do think could swing at least some votes). If Anthony's right and there's no chance it'll pass - no harm done, except for maybe we've lost a couple of weeks. Thoughts? Zeev After having thought a lot about it, I'll announce my intentions shortly in a separate thread and clarify the way this RFC will go. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On 15 03 2015, at 16:23, Levi Morrison le...@php.net wrote: On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner m...@php.net wrote: On 15 03 2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. I think it does raise a significant question around the voting practices. Something that I think we need to discuss as a group. So consider that discussion open. Jeez, that is becoming ridiculous. So, if you’re that good in counting, how many did not vote before STHv0.3? Is there a way to check when someone got a php.net account/karma? http://people.php.net http://people.php.net/
Re: [PHP-DEV] Voting irregularities
Is there a way to check when someone got a php.net account/karma? http://people.php.net I am aware of this, but unless I just missed it that site doesn't show *when* they got an account. Oh, sorry! I thought it reads something like “Account opened: Y-m-d” but that’s on the PECL site. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Voting irregularities
I am aware of this, but unless I just missed it that site doesn't show *when* they got an account. None of these accounts are recent as far as I can tell from my email archive. For the record, with the exception of Eli - with whom I discussed the reasons he voted against the Coercive RFC - I haven’t spoken with any of them and doubt anybody else did (not that it would have been forbidden if I or someone else did). Florian (IMHO obvious) explanation is the correct one. Take spriebsch for example - a very prominent figure in the PHP community, hardly a newcomer - and I guess it's the first time he finds something that's sufficiently important for him to vote on. We should really stop with the ridiculous offensive conspiracy theories. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A plea for unity on scalar types
On Mar 15, 2015 6:23 AM, Pavel Kouřil pajou...@gmail.com wrote: On Sun, Mar 15, 2015 at 9:56 AM, Leigh lei...@gmail.com wrote: On 15 March 2015 at 08:42, Pavel Kouřil pajou...@gmail.com wrote: Sure, per-file is better than ini setting, but better doesn't mean good (because it is still a pretty bad approach). The ini setting at least has the option to be turned off in code once everyone realizes it was a bad idea (register_globals via htaccess, for instance), but PHP would be stuck with the declare for a long time - this is not an easily revertable change, once PHP ships with it. The declaration is turned on with code. This is no different to changing an ini setting with code, except that it can't be configured globally in advance. Existing code is unaffected. I'm not sure where your not easily revertible argument is grounded. It's incredibly easy to add/remove declarations at the top of a file. So - are you saying that it would be easy to remove this feature from the language once people would realize it's register_globals (and any other settings that change how code behaves) all over again? The two groups (people who want strong typing and weak typing) will not work *together* though. And it will be a nightmare for everyone working on multiple projects from mulitple clients or so. Pure FUD. Sorry but there is no evidence to back this up. Well, how can there be evidence when the feature isn't released yet? But if you read through the discussions about the Dual Mode RFCs, you'll see that I'm definitely not the only userland developer with this opinion. Also, I can't think of any other language (apart from JS) which has some settings that change how the code behaves. I'd guess most languages don't do this for good reasons, but who knows, can't say for sure. The best approach to have some reasonable type rules is to progressively strenghten the rules (as Zeev's RFC tried to do so, but he probably did two steps in one RFC and that's what people dislike about it?). You think the best approach is to progressively and continually break working code between versions? How is this approach acceptable ever? This of course doesn't mean breaking existing code in every version. I doubt there would be more than 2 or 3 changes to the conversion rules in foreseeable future with this approach. But I do agree that this isn't ideal way to do things, but I'd say it's the right one. I think that PHP's type system would get to some equilibrium by this - people wanting stronger typing would tried to introduce it and people wanting weaker one would balance it and eventually there could be a point on which both sides could agree on. No, they would never reach agreement. Pure FUD. Sorry but there is no evidence to back this up. (Sorry, I had to - I really do believe that some consensus would be reached after a while, though.) I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the RFC being good for the userland developers in the long run. Apologies again, but I think you don't really understand what is being proposed in this RFC. Proponents of strict typing get exactly what they want, they can develop their library or entire project in strict mode if they want, and if someone wants to use this project or library, but themselves want to use weak mode, _nothing breaks_. Why does everyone reply to the disagreeing opinions with I think you don't understand the RFC? I've seen this happen multiple times in the discussions with Dual Mode RFC, even when the person understood the RFC. I am 100% aware that the caller decides the rules, not the callee and that there's supposed to be interoperability - and yet, I still strongly disagree with it, mostly because it makes managing multiple projects (each working with different mode) harder. I would generally love to have type hints in PHP 7.0 (with any reasonable ruleset, be it strongly typed, weakly typed or some middle ground, I don't care as long as it's only *one* ruleset), but I would rather have none than the Dual Mode one. Regards Pavel Kouril Interoperability issues? With an optional language feature? Rght
Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
On 15 March 2015 at 00:54, Niklas Keller m...@kelunik.com wrote: Morning, I'd like to announce that I'll open the vote for the in operator later that day. You can find the RFC here: https://wiki.php.net/rfc/in_operator We've discussed this elsewhere and the RFC is still lacking one thing - any justification of why this deserves being a new piece of syntax, rather than just being a function implemented either internally, or even better in userland PHP. I think that adding new syntax for something that could just be a function is not a good idea at the best of times, but when it's such generic keyword that could be far more useful in other places (e.g. Linq style queries) it really needs to have a strong justification. The equation is not just will PHP be better with this instead it's will PHP so much better that it justifies the known cost of adding syntax to the language, as well as the unknown cost of blocking future use of the 'in' keyword. I'm sorry, but I just can't see that the value in adding this comes anywhere close to justifying it's addition. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Voting irregularities
All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. I think it does raise a significant question around the voting practices. Something that I think we need to discuss as a group. So consider that discussion open. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
Hi Michael, On 15 March 2015 at 14:29, Michael Wallner m...@php.net wrote: Jeez, that is becoming ridiculous. So, if you’re that good in counting, how many did not vote before STHv0.3? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I don't think it's ridiculous in a separate thread around discussing voting practices. Anthony specifically notes that he is not calling them bad, or calling for them to be ignored in the context of the current RFCs. Merely noting that their existence has skewed this particular vote, as a recent ongoing example, which it has. I have to make an admission here, I cast a vote. I'm not on Anthony's list because I have used it previously a couple of times. I'm honestly a bit hesitant to believe I should have it, so I've deliberately moderated my voting. However, watching those with no prior voting history/or minimal history vote No compelled me to use it if only to offset one more arguably irregular vote by casting an opposing arguably irregular vote. Should people like me have a vote? I got it by contributing some code to PEAR long ago before I moved onto Zend Framework stuff, Mockery, and other things. I consider it a relatively small contribution, and the list makes clear many would prefer I didn't have a vote on that basis. I don't necessarily disagree with that sentiment, but we're stuck with the situation where contentious votes bring up the who deserves the right to vote debate from both sides (Anthony is hardly going solo in airing it here). The entire idea that such arguably irregular votes are spoiling RFC votes, i.e. not reflective of what the majority would consider votes by those who truly earned it, has been brought up by both sides to RFCs inside and outside of this list. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7
On Sun, Mar 15, 2015 at 6:34 AM, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2015-03-14 6:41 GMT+01:00 Levi Morrison le...@php.net: RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7 The proposal has changed from the original. It no longer reserves the aliases out of the interest of reserving the smallest useful, uncontroversial subset. Some people want to remove aliases for these types so in the interest of being as uncontroversial as possible I am no longer proposing to remove them. After this change I would change my vote to -1, because I would like the reserved type words to be consistent with those of the typecasts. While I agree that we should maybe drop aliases in typecasts like real, I don't think it makes sense to reserve Int for class names, when we don't reserve Integer etc. I may open the vote with multiple options, then. I really don't care about this detail. If people want the aliases that's reasonable, and if they don't want them that's reasonable too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [INFO] Basic Scalar Types
Hey, to clarify what the way to go with this RFC is. This RFC is a FALLBACK. It's about the common part of both other RFCs. That way it *only* will go to vote after Anthonys RFC ends. And *only* if it fails. That means, I will go by the voting RFC and wait until discussion period ends and put it to vote after Anthony closes his RFC in case it fails. I'm aware that a few people have said, they will change their vote depending on what ever might pass. And that they asked for this RFC going into direct competition against Anthonys RFC. No. Know what you want. If you dislike Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't switch your votes back and forth depending on what might win. That's why I decided to not have the vote on this running concurrently with Anthonys. But, in any case this RFC will go to vote on the 24th if Anthonys RFC couldn't gather a 2/3 supermajority. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Sun, Mar 15, 2015 at 9:30 AM, Michael Wallner m...@php.net wrote: On 15 03 2015, at 16:23, Levi Morrison le...@php.net wrote: On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner m...@php.net wrote: On 15 03 2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. I think it does raise a significant question around the voting practices. Something that I think we need to discuss as a group. So consider that discussion open. Jeez, that is becoming ridiculous. So, if you’re that good in counting, how many did not vote before STHv0.3? Is there a way to check when someone got a php.net account/karma? http://people.php.net I am aware of this, but unless I just missed it that site doesn't show *when* they got an account. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Sun, Mar 15, 2015 at 12:26 PM, Zeev Suraski z...@zend.com wrote: I am aware of this, but unless I just missed it that site doesn't show *when* they got an account. None of these accounts are recent as far as I can tell from my email archive. For the record, with the exception of Eli - with whom I discussed the reasons he voted against the Coercive RFC - I haven’t spoken with any of them and doubt anybody else did (not that it would have been forbidden if I or someone else did). Florian (IMHO obvious) explanation is the correct one. Take spriebsch for example - a very prominent figure in the PHP community, hardly a newcomer - and I guess it's the first time he finds something that's sufficiently important for him to vote on. We should really stop with the ridiculous offensive conspiracy theories. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Literally nothing Anthony said was ridiculous or a conspiracy theory. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7
Hi 2015-03-14 6:41 GMT+01:00 Levi Morrison le...@php.net: RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7 The proposal has changed from the original. It no longer reserves the aliases out of the interest of reserving the smallest useful, uncontroversial subset. Some people want to remove aliases for these types so in the interest of being as uncontroversial as possible I am no longer proposing to remove them. After this change I would change my vote to -1, because I would like the reserved type words to be consistent with those of the typecasts. While I agree that we should maybe drop aliases in typecasts like real, I don't think it makes sense to reserve Int for class names, when we don't reserve Integer etc. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A plea for unity on scalar types
Philip Sturgeon wrote:
On Sat, Mar 14, 2015 at 7:19 PM, Philip Sturgeon pjsturg...@gmail.com wrote:
On Fri, Mar 13, 2015 at 7:02 PM, Arvids Godjuks
arvids.godj...@gmail.com wrote:
пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturg...@gmail.com:
Pavel,
On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.
Hello,
I see (as a userland developer) these problems with dual mode:
- It is a setting that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.
- It does not unite different usages of PHP into a single group; it
does exactly the opposite, splitting PHP usage into TWO groups.
- Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.
(There's probably more of them, but these are the biggest issues I
currently have.)
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.
An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.
A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.
It seems like you didn't read anything now you're just saying it's
bad a lot. Please don't do that.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
That declare thing with the removal of block-aware declare(){} kills one of
the fundamental optimizations you can do for large PHP projects - compacting
most used files into one single big file and caching it. And you never had
to care what the files are - just splice it all together and let autoload
handle the rare cases. With single declare statement I effectivly have to
scan all the code, remove declare statements and choose a mode globally.
Well, it might work for a small project, but in a big project with multiple
teams or even multiple vendors doing different parts
At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.
You really had to fuck it all up for us, the userland developers, didn't
you?
Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote no. And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave the
project for good after this.
Wow, that's a lot of rage over nothing. Here, I got you a gift:
foreach (new DirectoryIterator('./src/**/*.php') as $fileInfo) {
$fileContents = file_get_contents($fileInfo-getFilename());
if (strpos($fileContents, 'declare(strict_types=1') !== 0) {
$fileContents = str_replace(declare(strict_types, #
declare(strict_types, $fileContents);
file_put_contents('./compiled/weak.php', $fileContents, FILE_APPEND);
} else {
file_put_contents('./compiled/strict.php', $fileContents, FILE_APPEND);
}
}
Tadaaa.
Phil Sturgeon. Problem solver. Fixer of the bad day. Userland Ninjitsu. :)
I would like to appologize for my previous email. ..
It contained quite a serious oversight.
if (strpos($fileContents, 'declare(strict_types=1') !== true) {
That's better.
Wouldn't the condition be always true in this case? Testing for ===
false seems to be more appropriate.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Minimum version of GCC required to build PHP
On 15 03 2015, at 16:36, Sebastian Bergmann sebast...@php.net wrote: Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann: I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA). Over in Room 11, Michael just pointed out that this could be related to php_stdint.h. Yes, we could probably just add a check whether intptr_t is defined and if not do so according to the bit width of the platform. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On 15.03.2015 16:44, Pádraic Brady wrote: I don't think it's ridiculous in a separate thread around discussing voting practices. Anthony specifically notes that he is not calling them bad, or calling for them to be ignored in the context of the current RFCs. Merely noting that their existence has skewed this particular vote, as a recent ongoing example, which it has. I have to make an admission here, I cast a vote. I'm not on Anthony's list because I have used it previously a couple of times. I'm honestly a bit hesitant to believe I should have it, so I've deliberately moderated my voting. However, watching those with no prior voting history/or minimal history vote No compelled me to use it if only to offset one more arguably irregular vote by casting an opposing arguably irregular vote. Maybe many people don't see it that way, but for example for me there's hardly been any RFC that would shape the *spirit* of the language as much as this RFC. So I think that's a perfectly valid reason to - for the first time ever - pitch in with your vote, even if it's not the case for me personally. The entire idea that such arguably irregular votes are spoiling RFC votes, i.e. not reflective of what the majority would consider votes by those who truly earned it, has been brought up by both sides to RFCs inside and outside of this list. I don't think it's possible to create a system that a) represents the majority of PHP users b) represents the most active contributors to internals c) can't be gamed in any way. We have this system now and until a RFC comes along to change voting rights or revert to the old do what you want until someone calls you out on it there's hardly some constructive discussion about it in all the threads where it came up. Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
On 15 03 2015, at 17:09, Dan Ackroyd dan...@basereality.com wrote: Hi List, The 'Constructor behaviour of internal classes' RFC is now in voting. Please note, it's the coding standard that is being voted on. If anyone thinks I've implemented the changes in a way that is less awesome then there is no reason the changes couldn't be improved. Additionally, while writing the change I noticed some things that were already present in the code, that are outside the scope of the RFC but ought to be fixed for the release of PHP 7. * Multiple examples of a generic Exception being thrown rather than a specific exception being thrown. * Code generating an error notice and throwing an exception. It should be one or the other, not both. * The text of exceptions in Intl not always being as informative as the error message, which could be improved. But as I said, the vote is on whether the standard behaviour of either returning a working instance or throwing an exception, is the standard behaviour we want in PHP. For the lazy people, like me: https://wiki.php.net/rfc/internal_constructor_behaviour#voting https://wiki.php.net/rfc/internal_constructor_behaviour#voting
Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
Hi Matteo, On 15 March 2015 at 10:29, Matteo Beccati p...@beccati.com wrote: Disclaimer: I do know a little about security, but I am not a crypto-expert by any means. If I'm saying something silly, just let me know ;) I want to vote yes, but naming is something that scares me a bit. Without any indication that it's CSPRNG, people might start using it even when unnecessary, and I'd be worried about potential negative effects, such as exhausting the entropy pool. It's probably more of a documentation problem, but we know many won't read the docs and a hint in the function name could help guiding users. Were folk to use random_int() by default, it would be actually be considerably better than the situation today where many reach for mt_rand() without really considering the use case. Using a strong source of ints instead of a weak source still ends up with you getting the requested ints. There's no downside unless the source is blocking. Using the weak source over a strong source will also get you ints, but without knowing the use, it has the immediate downside risk of being from a weak source which shouldn't be used for anything requiring strong randomness. So random_int() really is the best first default option to go for when in doubt, with some careful consideration before switching to mt_rand(). As for exhausting the entropy pool, this is something of a misconception. The sources in the RFC are pseudorandom generators which won't exhaust the entropy pool by design. For example, it would be overkill to use random_int() to randomly pick the content of a boxes at each reload of a web page, but if what I need is a *random int*, then random_int() seems a far better choice than some obscure rand() or mt_rand(). Or in the poker deck example, wouldn't it be enough just to seed mt_srand with a crypto-secure number to remove the biasing and using mt_rand to shuffle the deck? In essence, this is what the functions are already providing an interface to: systems which take a truly random seed and output pseudorandom values. The difference is that the underlying system is designed to be cryptographically secure (for most uses). mt_rand(), on the other hand, is not. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A plea for unity on scalar types
On Sun, Mar 15, 2015 at 4:52 AM, Pavel Kouřil pajou...@gmail.com wrote:
So - are you saying that it would be easy to remove this feature from
the language once people would realize it's register_globals (and any
other settings that change how code behaves) all over again?
Actually, it would be very easy to remove this from the language.
There is no possible way to rely on strict hints over auto-cast hints
in such a way that would break your application by any meaningful
definition of the word.
?php
declare(strict_types=1);
function foo(int $i) : int
{
if (!is_int($i)) die('How did we get here?');
return $i + 1;
}
echo foo(1);
?
Output, after strict_types has been removed from language:
E_NOTICE: strict_types is no longer supported.
2
Yes, that would have previously thrown an exception, but the behavior
after removing strict types from the language really hasn't broken
anything. This is nothing like removing register_globals... where
entire apps silently break without any good way to track down how and
where.
Honestly, I think the reverse of your scenario is more likely.
1) Only the strict_types=0 mode is implemented, using same rules as
standard PHP casts. (basic_scalar_types)
2) xdebug adds a feature to enable the equivalent of strict_types=1
for debug mode.
3) People realize this is super useful and request please allow a
whitelist while debugging so I can debug my app in pieces and ask
how can we optionally enable this during production mode?
4) declare(strict_types=1) is proposed for support in PHP without
xdebug, and is accepted.
:)
Finally, the voting process on these two RFCs is absurd, and even more
absurd with the proposal of a third one. Very few people are going to
play fair and vote YES on multiple of them, even if they would vote
YES if it was the only proposal. As I've said before, the best way to
reach consensus on *large, grand ideas* (i.e., not petty details) is
to hold an instant runoff on a single vote. e.g., Rank your choices in
order of preference: scalar_type_hints_v5, coercive_sth,
basic_scalar_types, none. First to 2/3's win, after eliminating the
least popular vote each round. (Could still end up with a winner
2/3s, which would just mean the RFC failed.) I sincerely hope this
type of vote is added as an option for future RFCs when appropriate,
so that we never have to go through this terrible process again.
(PS: I have nothing against the RFC authors; on the contrary, I
respect all of the work they have put into their proposals. So big
thanks to all of you!)
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On 15 03 2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. I think it does raise a significant question around the voting practices. Something that I think we need to discuss as a group. So consider that discussion open. Jeez, that is becoming ridiculous. So, if you’re that good in counting, how many did not vote before STHv0.3? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Minimum version of GCC required to build PHP
Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann: I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA). Over in Room 11, Michael just pointed out that this could be related to php_stdint.h. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Reclassify E_STRICT notices
Hi internals! To ensure we have no shortage of new RFC votes... https://wiki.php.net/rfc/reclassify_e_strict#vote Voting is open for ten days :) Thanks, Nikita
Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7
On Sat, Mar 14, 2015 at 4:30 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 03/15/2015 07:31 AM, Philip Sturgeon wrote: On Sat, Mar 14, 2015 at 7:38 AM, Bob Weinand bobw...@hotmail.com wrote: Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajou...@gmail.com: On Saturday, March 14, 2015, Levi Morrison le...@php.net wrote: RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7 The proposal has changed from the original. It no longer reserves the aliases out of the interest of reserving the smallest useful, uncontroversial subset. Some people want to remove aliases for these types so in the interest of being as uncontroversial as possible I am no longer proposing to remove them. This will go into voting on March 15th unless something comes up between now and then to persuade me otherwise. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, why do you consider a true and false as a type? It's not a type. it's a value? Regards Pavel Kouril These aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…] Also, he doesn't call them anywhere types, it's just the title. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php This is a solid plan. Vote this and everyone should +1 it, so if this scalar squabble results in a a 0-0-0 score we can at least add scalars later. This is not quite that obvious I don't think. If https://wiki.php.net/rfc/context_sensitive_lexer isn't ready in time for 7.0 and we don't need to reserve these for one of the STH RFCs then we should hold off and do it alongside the context sensitive lexer change or we are going to needlessly break a ton of code including Drupal8: https://github.com/drupal/drupal/blob/8.0.x/core/lib/Drupal/Component/Utility/String.php#L15 -Rasmus I respect this opinion, though I disagree. I do agree that breaks in backwards compatibility should not be taken lightly; I think we just disagree on the magnitude of both the breaks and the gains. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
Hi List, The 'Constructor behaviour of internal classes' RFC is now in voting. Please note, it's the coding standard that is being voted on. If anyone thinks I've implemented the changes in a way that is less awesome then there is no reason the changes couldn't be improved. Additionally, while writing the change I noticed some things that were already present in the code, that are outside the scope of the RFC but ought to be fixed for the release of PHP 7. * Multiple examples of a generic Exception being thrown rather than a specific exception being thrown. * Code generating an error notice and throwing an exception. It should be one or the other, not both. * The text of exceptions in Intl not always being as informative as the error message, which could be improved. But as I said, the vote is on whether the standard behaviour of either returning a working instance or throwing an exception, is the standard behaviour we want in PHP. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls
Hi, I received some requests to update the RFC with more information about BC breaks + possible minor adjustments regarding dynamic function calls. So I decided to drop the current voting, while it's still on the beginning, to properly update the RFC. We had 7 votes computed - 4 yes and 3 no votes. If you already voted, don't worry, it's just some minor changes and the voting will be restarted by the end of the day (March 15) so we don't loose the schedule. Another email will follow with a summary of what changed. Thanks for the comprehension. 2015-03-14 20:54 GMT-03:00 Marcio Almada marcio.w...@gmail.com: Hi, The Strict Argument Count RFC is now on voting phase: RFC: https://wiki.php.net/rfc/strict_argcount PR: https://github.com/php/php-src/pull/1108 The voting will close in exactly 14 days counting from now (using the date/time from this email as a reference). If you have any doubt about what was already discussed, please refer to this aggregated markmail summary http://markmail.org/thread/ol5s2vhw35ac2px3 Please read the RFC with full attention and good voting! :) Thanks, Márcio
Re: [PHP-DEV] [VOTE] [RFC] continue output buffering
Voting just started on https://wiki.php.net/rfc/continue_ob https://wiki.php.net/rfc/continue_ob I’ll close the poll in a week. Thanks, Mike
Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7
On Sat, Mar 14, 2015 at 12:38 PM, Bob Weinand bobw...@hotmail.com wrote: Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajou...@gmail.com: On Saturday, March 14, 2015, Levi Morrison le...@php.net wrote: RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7 The proposal has changed from the original. It no longer reserves the aliases out of the interest of reserving the smallest useful, uncontroversial subset. Some people want to remove aliases for these types so in the interest of being as uncontroversial as possible I am no longer proposing to remove them. This will go into voting on March 15th unless something comes up between now and then to persuade me otherwise. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, why do you consider a true and false as a type? It's not a type. it's a value? Regards Pavel Kouril These aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…] Also, he doesn't call them anywhere types, it's just the title. Bob Hello, a union type would be an union of types - so it should be int|bool, shouldn't it? (Also, I don't personally like the idea of union types in general, but it's not relevant to the current RFC, so I won't comment more on that issue.) Still, maybe the title of the RFC should change to Reserve More Keywords in PHP 7, so it's not misleading? PS: Thanks for the info about internal stuff, didn't know about that. :) Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SAPI apache2handler + pipelined HTTP request core dumps
Respin of my patch for https://bugs.php.net/bug.php?id=68486 is now available as a gist here: https://gist.github.com/bof/15173c7a11cb12a7b96f Some comments on the respin are in the bug report at [2015-03-15 10:17 UTC] Debug cruft has been removed, and as far as my brain can make out this is now something that might just survive in production :) so please test best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A plea for unity on scalar types
On 15 March 2015 at 08:42, Pavel Kouřil pajou...@gmail.com wrote: Sure, per-file is better than ini setting, but better doesn't mean good (because it is still a pretty bad approach). The ini setting at least has the option to be turned off in code once everyone realizes it was a bad idea (register_globals via htaccess, for instance), but PHP would be stuck with the declare for a long time - this is not an easily revertable change, once PHP ships with it. The declaration is turned on with code. This is no different to changing an ini setting with code, except that it can't be configured globally in advance. Existing code is unaffected. I'm not sure where your not easily revertible argument is grounded. It's incredibly easy to add/remove declarations at the top of a file. The two groups (people who want strong typing and weak typing) will not work *together* though. And it will be a nightmare for everyone working on multiple projects from mulitple clients or so. Pure FUD. Sorry but there is no evidence to back this up. PHP will IMHO never be strongly-typed by default. Probably. The best approach to have some reasonable type rules is to progressively strenghten the rules (as Zeev's RFC tried to do so, but he probably did two steps in one RFC and that's what people dislike about it?). You think the best approach is to progressively and continually break working code between versions? How is this approach acceptable ever? I think that PHP's type system would get to some equilibrium by this - people wanting stronger typing would tried to introduce it and people wanting weaker one would balance it and eventually there could be a point on which both sides could agree on. No, they would never reach agreement. I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the RFC being good for the userland developers in the long run. Apologies again, but I think you don't really understand what is being proposed in this RFC. Proponents of strict typing get exactly what they want, they can develop their library or entire project in strict mode if they want, and if someone wants to use this project or library, but themselves want to use weak mode, _nothing breaks_.
Re: [PHP-DEV] Re: A plea for unity on scalar types
On Sun, Mar 15, 2015 at 9:56 AM, Leigh lei...@gmail.com wrote: On 15 March 2015 at 08:42, Pavel Kouřil pajou...@gmail.com wrote: Sure, per-file is better than ini setting, but better doesn't mean good (because it is still a pretty bad approach). The ini setting at least has the option to be turned off in code once everyone realizes it was a bad idea (register_globals via htaccess, for instance), but PHP would be stuck with the declare for a long time - this is not an easily revertable change, once PHP ships with it. The declaration is turned on with code. This is no different to changing an ini setting with code, except that it can't be configured globally in advance. Existing code is unaffected. I'm not sure where your not easily revertible argument is grounded. It's incredibly easy to add/remove declarations at the top of a file. So - are you saying that it would be easy to remove this feature from the language once people would realize it's register_globals (and any other settings that change how code behaves) all over again? The two groups (people who want strong typing and weak typing) will not work *together* though. And it will be a nightmare for everyone working on multiple projects from mulitple clients or so. Pure FUD. Sorry but there is no evidence to back this up. Well, how can there be evidence when the feature isn't released yet? But if you read through the discussions about the Dual Mode RFCs, you'll see that I'm definitely not the only userland developer with this opinion. Also, I can't think of any other language (apart from JS) which has some settings that change how the code behaves. I'd guess most languages don't do this for good reasons, but who knows, can't say for sure. The best approach to have some reasonable type rules is to progressively strenghten the rules (as Zeev's RFC tried to do so, but he probably did two steps in one RFC and that's what people dislike about it?). You think the best approach is to progressively and continually break working code between versions? How is this approach acceptable ever? This of course doesn't mean breaking existing code in every version. I doubt there would be more than 2 or 3 changes to the conversion rules in foreseeable future with this approach. But I do agree that this isn't ideal way to do things, but I'd say it's the right one. I think that PHP's type system would get to some equilibrium by this - people wanting stronger typing would tried to introduce it and people wanting weaker one would balance it and eventually there could be a point on which both sides could agree on. No, they would never reach agreement. Pure FUD. Sorry but there is no evidence to back this up. (Sorry, I had to - I really do believe that some consensus would be reached after a while, though.) I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the RFC being good for the userland developers in the long run. Apologies again, but I think you don't really understand what is being proposed in this RFC. Proponents of strict typing get exactly what they want, they can develop their library or entire project in strict mode if they want, and if someone wants to use this project or library, but themselves want to use weak mode, _nothing breaks_. Why does everyone reply to the disagreeing opinions with I think you don't understand the RFC? I've seen this happen multiple times in the discussions with Dual Mode RFC, even when the person understood the RFC. I am 100% aware that the caller decides the rules, not the callee and that there's supposed to be interoperability - and yet, I still strongly disagree with it, mostly because it makes managing multiple projects (each working with different mode) harder. I would generally love to have type hints in PHP 7.0 (with any reasonable ruleset, be it strongly typed, weakly typed or some middle ground, I don't care as long as it's only *one* ruleset), but I would rather have none than the Dual Mode one. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static constructor
I think I now get the misunderstanding I had on your destructor question Sorry for confusion. My points are agnostic about implementation details and concrete code. It's up to ppl to use this feature as they like. - first point is a logical conclusion: If there is a cctor, there should be a cdtor. - second point is about implicit order: Shutdown process will free in reversed creation order. Classes don't have guaranteed creation order. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static constructor
Am 15.03.2015 um 11:02 schrieb Crypto Compress:
I think I now get the misunderstanding I had on your destructor question
Sorry for confusion. My points are agnostic about implementation details
and concrete code. It's up to ppl to use this feature as they like.
Okay get your point, but as already discussed several times, the rfc
should not be declined for the reason a ppl, who doesn't understand when
to use static context or when not to use at all, can do crucial things.
Because he although can do without the static constructor.
For a horiffic example:
class Example {
private static $handler;
public function open() {
self::$handler = fopen('example.txt');
}
...
}
Example::open();
Indeed I have the opinion some beginner who is doing such horiffic code
maybe think more about what he is doing and especially about the side
effects inside a so called magic method, then outside.
- first point is a logical conclusion: If there is a cctor, there should
be a cdtor.
Okay the logical conclusion I can take in count. But doing 15 years of
OOP-programming now, I never had the need to have a cdtor, for a valid
usage of static context. And still after I have seen your examples,
which should all be done, as I explained, with instances instead of
direct static binding, I don't see the use case for a cdtor.
- second point is about implicit order: Shutdown process will free in
reversed creation order. Classes don't have guaranteed creation order.
But I hope shutdown process of PHP is as intelligent not do unload a
class which is needed in another class before this class?!
Regards,
--
DerOetzi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls
On 15 March 2015 at 06:59, Marcio Almada marcio.w...@gmail.com wrote: Hi, I received some requests to update the RFC with more information about BC breaks + possible minor adjustments regarding dynamic function calls. Please can you stop abusing the RFC process? This RFC is attempting to change the language. You received the information about the BC breaks weeks ago, they aren't new items that you just heard about for the first time today.. You opened the voting and then closed it immediately when you realised the vote wasn't going to sail through. You're now making changes to the RFC and proposing to re-open voting on the same day. How are people meant to have time to read and think about the changes? It's also going to be impossible for people to try the patch out, or to measure it for performance hit. The problem this RFC fixes is not a big enough problem to justify making decisions about the language at the last minute, particularly as the last version of the RFC I read breaks a whole load of valid code. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Foo::bar(); // OK ['Foo', 'bar'](); // OK 'Foo::bar'(); // FATAL ERROR Hi, does this topic need to be addressed before PHP7 goes feature freeze? Or is it a bugfix? (Julien already provided a patch) I'm not familiar with writing RFCs. I fear I won't be able to handle it on schedule if one is required. Can someone help please? Regards, Nicolas
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann: So who will draft the RFC for * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engine ? It was my idea, after all, only fair that I invest the time to make it into an RFC: https://wiki.php.net/rfc/throwable Please let me know if there is anything missing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reclassify E_STRICT notices
On Mon, Mar 2, 2015 at 7:13 PM, Julien Pauli jpa...@php.net wrote: On Wed, Feb 25, 2015 at 10:32 AM, Derick Rethans der...@php.net wrote: On Sun, 22 Feb 2015, Nikita Popov wrote: I would like to propose reclassifying our few existing E_STRICT notices and removing this error category: https://wiki.php.net/rfc/reclassify_e_strict As we don't really have good guidelines on when which type of error should be thrown, I'm mainly going by what category other similar errors use. I'm open to suggestions, but hope this will not deteriorate into total bikeshed. Those guidelines where part of the original proposal though: http://grokbase.com/t/php/php-internals/06aq0a1vzx/rfc-e-deprecated Which interestingly mentions your Abstract static methods case. And I did write something up (with my opinions of it): http://derickrethans.nl/erecoverableerror.html In any case, some comments on a few of the cases: Redefining a constructor - I think that should be retained (or an E_NOTICE) as it's something that might catch people out. I think it helps enough to warrant it. Same (compatible) property in two used traits - I think that should be changed to an E_NOTICE, or not at all, if it's already an E_NOTICE. For a similar reason as above. Accessing static property non-statically - I think this should stay E_STRICT, as it falls in the original proposal's category of any rule that reflects common strict standards, like OOP theory that is considered harmless if not followed I'm not against removing E_STRICT and reclassifying the errors, however, like Derick , I'd like to keep the trait and redefining constructor ones as they may really help to spot problems. The redefining constructor notice is already gone with the ctors RFC, so I won't comment on that. Regarding the trait warning: There is a tradeoff between a) this notice can spot problems and b) this notice completely disallows using this feature in professional code. I don't think having the same property in two traits is in any way fundamentally wrong if the declarations are compatible, so I don't see why we should (effectively) completely forbid it. Nikita
Re: [PHP-DEV] Re: SAPI apache2handler + pipelined HTTP request core dumps
Am 15.03.2015 11:20 schrieb Patrick Schaaf p...@bof.de: Respin of my patch for https://bugs.php.net/bug.php?id=68486 is now available as a gist here: https://gist.github.com/bof/15173c7a11cb12a7b96f Some comments on the respin are in the bug report at [2015-03-15 10:17 UTC] Debug cruft has been removed, and as far as my brain can make out this is now something that might just survive in production :) so please test To be explicit, I did NOT test - any apache worker except prefork - any kind of threadsafe build - any other OS than Linux (opensuse 13.1 + 11.4) - any other PHP than 5.6.7RC1 Patrick
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Am 27.02.2015 um 15:47 schrieb Jordi Boggiano: quickly draft another RFC to amend that part So who will draft the RFC for * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engine ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sun, Mar 15, 2015 at 8:27 AM, Sebastian Bergmann sebast...@php.net wrote: Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann: So who will draft the RFC for * Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engine ? It was my idea, after all, only fair that I invest the time to make it into an RFC: https://wiki.php.net/rfc/throwable Please let me know if there is anything missing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, why global namespace? Why not just starting using namespaces for PHP stuff? The global namespace gets more and more polluted by this IMHO. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
2015-03-15 3:34 GMT+01:00 Stanislav Malyshev smalys...@gmail.com: Hi! I'd like to announce that I'll open the vote for the in operator later that day. You can find the RFC here: https://wiki.php.net/rfc/in_operator I think this operator is unnecessary - we already have perfectly good function that does the same. If they were perfectly good, ... Also, since it checks the values and not the keys, it would be useless for the same use case one would most frequently use in in Python and such - for checking if something is in a set of values. Since efficient implementation of the set in PHP would have the value being sought as key, in would be useless, unless much slower iterative implementation is chosen. We already have a language construct here that's not a function call: isset. Also, because it includes different (and inconsistent) implementation for strings, if you have (foo in $bar === true) , you don't know if $bar is an array that includes string foo or a string that has foo as a substring. I don't think it's good that operator would mix these two cases. It's different for strings, yes, but where's the inconsistency? A common user case would probably be checking user input against a set of values. As others already mentioned in the discussion there have been security issues using non-strict in_array in the past. -- Stas Malyshev smalys...@gmail.com Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
On 15/03/2015 04:23, Sammy Kaye Powers wrote: A two week discussion period has been held for the reliable user-land CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now been moved into voting. https://wiki.php.net/rfc/easy_userland_csprng There was some discussion of prefixing the function names with `crypto_*()` but there are a few reasons we decided against this: 1) There is a crypto pecl extension, so the pseudo-namespace might cause confusion. 2) We want to work on a fully featured crypto framework for 7.1, and crypto_* is a good prefix for that, so again, we don't want to mix things up. Disclaimer: I do know a little about security, but I am not a crypto-expert by any means. If I'm saying something silly, just let me know ;) I want to vote yes, but naming is something that scares me a bit. Without any indication that it's CSPRNG, people might start using it even when unnecessary, and I'd be worried about potential negative effects, such as exhausting the entropy pool. It's probably more of a documentation problem, but we know many won't read the docs and a hint in the function name could help guiding users. For example, it would be overkill to use random_int() to randomly pick the content of a boxes at each reload of a web page, but if what I need is a *random int*, then random_int() seems a far better choice than some obscure rand() or mt_rand(). Or in the poker deck example, wouldn't it be enough just to seed mt_srand with a crypto-secure number to remove the biasing and using mt_rand to shuffle the deck? Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static constructor
Am 13.03.2015 um 01:33 schrieb Christoph Becker:
Johannes Ott wrote:
And i although see no DI or Singleton pattern to use here to get the
same functionality, if you want to use like Config::getHostname() and
not like Config::getInstance()-getHostname() which is really
unnecessary abstraction level for nothing in my opinion!
It is possible, however, to add static wrapper methods to access the
singleton's methods, like
public static function getHostname() {
return self::getInstance()-_getHostname();
}
It is not only about the extra method-call but although the additional
Null check inside this method call.
Let's do some calculation for that: in average I have 5 calls of the
logger per method the message is used 10 times during the programm.
Now we already have 49 unnecessary method calls (with all needed to do
for the interpreter like preparing stack, copying the returns etc.) and
40 unnecassary null checks inside (as we agreed before that is not
counted fully, because the evaluation of the flag will although take
some time but can be more efficient inside the interpreter). Let's now
think only about 10 such methods we are already at a count of 490
unnecessary method calls. Maybe only slightly worse performance but it
is a performance issue! And there is this very old performance rule: a
lot of small performance issues can become quickly to a huge one.
I have counted the calls in code of self::$LOG- inside one small
private webproject of mine with less logging implemented yet. But there
are already 128 calls. If you multiply by 10 you already have 1280 calls
on runtime, I think that is a performance issue.
It seems to me that the logger example is not appropriate to show
performance penalties due to unnecessary method calls and null checks,
because the actual task of the logger (write to a file/database, or even
send an email) is easily much more demanding performance-wise.
Anyhow, in my humble opionion, there had been enough initial discussion
on this idea, and it would be reasonable to proceed with the actual RFC.
See How To Create an RFC[1] and especially The Mysterious PHP RFC
Process and How You Can Change the Web[2]. :)
[1] https://wiki.php.net/rfc/howto
[2] https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
I tried to get some RFC karma for my wiki account, following those lines:
Email internals@lists.php.net requesting RFC karma for your wiki
account. In the email, remind people about the RFC you plan to create.
Note that RFC karma does not automatically give you karma to vote. See
https://wiki.php.net/rfc/voting#rfc_proposer
I didn't get any reaction on my mail for three days, is this normal or
have I done something wrong?
Thanks for your help
Regards,
--
DerOetzi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices
On 15.03.15 16:46, Nikita Popov wrote: To ensure we have no shortage of new RFC votes... https://wiki.php.net/rfc/reclassify_e_strict#vote Voting is open for ten days :) From the RFC: Signature mismatch during inheritance ... Possible alternative: Convert to E_DEPRECATED, if we intend to make this a fatal error in the future. Has there been any decision made which course to follow? I ask since I don't see voting option for it (not saying it needs one!), it just would be nice to carve in stone what's going to be done about it. Otherwise good cleanup RFC IMHO, +1 - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Am 15.03.2015 um 17:55 schrieb Zeev Suraski z...@zend.com: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. Why am I making this admittedly big move? I think that waiting until we know for certain whether the Dual Mode STH would win is very problematic, for two reasons. The bigger one that it runs a serious risk we have no STH at all for 7.0. It's not an unlikely scenario either - it's probably 50/50% that the Dual STH RFC would fail, only to find later - when it's too late - that Strict campers have enough votes to block the Basic one. Personally, I find that the worst possible outcome, given how clearly it is that the users at large want *something*. If the Basic RFC is put to a vote but retracted if when we see it stands no chance to pass - combined with my commitment to support the Dual STH in such a case (and my belief that move will be able to influence others as well), the chances that we'd be left with no STH at all for 7.0 goes down significantly. There's also a secondary reason - I do think it's unfair that in a very likely scenario - we won't be giving people who prefer Basic STH only - at least at this point - a chance to vote at the proposal they think is best. I don't think it's a matter of voting for who's going to win; In fact with a commitment to retract it if it fails to win, it's not about that at all. It's being able to vote for what you truly believe in, as opposed to a compromise that you find bad but better than nothing. And in my case (and perhaps others) - it's about being willing to vote for something I actually don't believe it at all for the sake of unity, but only once the alternative options have been explored. Before Dual STH supporters dissect my move to pieces, please realize this: If you're right - that Basic STH stands no chance to gain 2/3 majority - you have absolutely NOTHING to lose, and in fact, you're increasing your chances of passing that vote through from apparently 50/50 to 80/20 (not talking about votes, but chances), and as a bonus, you get to prove your point. If you're wrong - and Basic STH is more popular than Dual STH (at this point in time) - we would have given the community at large something that's closer to what it really wants. Zeev -Original Message- From: Bob Weinand [mailto:bobw...@hotmail.com] Sent: Sunday, March 15, 2015 5:51 PM To: PHP Internals Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar Types Hey, to clarify what the way to go with this RFC is. This RFC is a FALLBACK. It's about the common part of both other RFCs. That way it *only* will go to vote after Anthonys RFC ends. And *only* if it fails. That means, I will go by the voting RFC and wait until discussion period ends and put it to vote after Anthony closes his RFC in case it fails. I'm aware that a few people have said, they will change their vote depending on what ever might pass. And that they asked for this RFC going into direct competition against Anthonys RFC. No. Know what you want. If you dislike Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't switch your votes back and forth depending on what might win. That's why I decided to not have the vote on this running concurrently with Anthonys. But, in any case this RFC will go to vote on the 24th if Anthonys RFC couldn't gather a 2/3 supermajority. Thanks, Bob Please do not top post... Zeev, I'm sure we risk to have no STH at all in PHP 7.0 if I put it into vote now. Some people will change their vote, not enough people for basic to pass. Also, I definitely won't support going back and forth with the votes. If you have issues with dual mode, vote against it. If you like the Basic Types RFC, vote in favor of it, once it starts. You're all given a chance. We should have a version of STH we have *consensus* on, not some type of STH most people dislike, just for the sake of it. Please respect my stance on that. Thus, I deny your request and strongly urge you to *not* fork my RFC. That would be sabotaging of Anthony's and my RFC. I won't tolerate that. You had a time to do this RFC, but you did coercive. Now, it's my move with this RFC and not yours. Please accept that and don't play against us. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On 15/03/2015 14:19, Anthony Ferrara wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. I think calling this an irregularity is going a bit far. It's an interesting observation, but since this is such a contentious issue, the question I would be asking is what these people have in common that makes them likely to vote no - are they from a particular part of the community whose voice is less often heard, for instance? As I've just said on Twitter before seeing this thread, these are really small sample sizes, and the way you've framed the statistics there makes it sound more significant than it is. Wolfram Alpha tells me that if 12 people chose their vote by tossing a coin, there's a probability of 0.073 that 9 of them would vote the same way, which is higher than the threshold of 0.05 traditionally set for significance. I don't know if that's a valid statistic, but it's at least as scientific as your whopping 24.3%. If you look at those users as a proportion of the complete turnout, you get 11.11% (1 in 9) votes coming from first-time voters. The net impact is 6 votes out of 108, which is about 5.5%; that happens to be enough to stop this vote crossing the line right now, but only because the vote is so close anyway. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. If you exclude an arbitrary subset of votes in a close ballot like this, it's easy to edge it past the finishing post, but that's really an abuse of statistics. For instance, you could say that if the vote was closed on date X, the result would have been Y, but you can't know that there weren't people who'd already decided which way they were voting, but hadn't got round to logging in, because they knew the vote wasn't due to close yet. With more research, you could come up with other interesting subsets, like people who've voted less than X times, or not voted in the last X months. But if you're going to play with statistics, you should be rigourous in defining your hypothesis, and how you'll measure the significance of your result. Alternatively, leave the statistics out of it, and say that you're interested to know why these first-time voters voted how they did. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices
Hi Nikita, On 15/03/2015 16:46, Nikita Popov wrote: Hi internals! To ensure we have no shortage of new RFC votes... https://wiki.php.net/rfc/reclassify_e_strict#vote Voting is open for ten days :) I know I'm late, but with I just have found the required time to test the branch with my own legacy app. The result of the test suite run is pretty bad because of the new warnings. More than half of the tests fail with a message similar to: https://revive.beccati.com/bamboo/browse/REV-EXP-NIK-1/test/case/19183062 Now, some of them would be fairly easy to fix. But, once again the problem lies in the bundled PEAR libs. For example the raiseError() method has been redefined all over the place with a custom signature. Fixing is certainly possible, but fixing will require a fairly big refactoring. In PHP4 times it was in fact quite common to change inherited method signatures to bend them to one's will and/or remove parameters and hardcode them in the parent constructor call. We now know it is bad practice, but I bet there's lot of code using these practices in controlled situations. I'm going to attempt fixing the app code (including the bundled pear libs) and report back. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
What we need, is a MANAGER! To manage the Type Hint development. And one that is not doing real development on PHP core, but someone with understanding. You are basically saying we should hand development of a critical language feature over to someone not doing real development on the language. I don't see how that could possibly end well. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015 17:59:17 GMT+00:00: On 15/03/2015 14:19, Anthony Ferrara wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. I think calling this an irregularity is going a bit far. I don't think it's going to far, if you have people with no clue writing this: https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB Which post says that we're turning PHP into Java. And to this misguided FUD post, that actively asks people to vote no, I can quite easily attribute a few more no votes of people that had never voted before... Too late to tighten up the rules for this one, but something is definitely not right with the current process. Cheers, Derick -- http://derickrethans.nl | http://xdebug.org twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Zeev, On Sun, Mar 15, 2015 at 3:07 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pádraic Brady [mailto:padraic.br...@gmail.com] Sent: Sunday, March 15, 2015 9:00 PM To: Zeev Suraski Cc: Bob Weinand; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types On 15 March 2015 at 16:55, Zeev Suraski z...@zend.com wrote: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. No one individual has the right to break the existing rules around voting. There has been more than sufficient time to date to rewrite the voting rules, debate voting rights, extend PHP7's deadline, or propose the basic RFC so described. A vote in contravention of the voting rules at the last possible minute cannot, by definition, be recognised at this time. I wouldn't even vote since it might lend it an air of ill deserved legitimacy, forgetting for a moment whether a few PEAR contributions make me any more deserving of a vote than others. No rule is being broken. The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the following: Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+ additional months) As Bob pointed out, what 'Line up' means - whether it means vote ends, vote begins, or discussion begins - is completely open to interpretation. I don't remember what I meant when I wrote it, but arguably, 'line up' is a lot closer to 'start discussing' than 'finish voting', and as is typically the case when something is unclear, the most lax interpretation is acceptable. By your own words: http://marc.info/?l=php-internalsm=142451267910615w=2 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. **votes to begin by March 15**. That was the interpretation you used a month ago. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Sunday, March 15, 2015 9:11 PM To: Zeev Suraski Cc: Pádraic Brady; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types Zeev, On Sun, Mar 15, 2015 at 3:07 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pádraic Brady [mailto:padraic.br...@gmail.com] Sent: Sunday, March 15, 2015 9:00 PM To: Zeev Suraski Cc: Bob Weinand; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types On 15 March 2015 at 16:55, Zeev Suraski z...@zend.com wrote: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. No one individual has the right to break the existing rules around voting. There has been more than sufficient time to date to rewrite the voting rules, debate voting rights, extend PHP7's deadline, or propose the basic RFC so described. A vote in contravention of the voting rules at the last possible minute cannot, by definition, be recognised at this time. I wouldn't even vote since it might lend it an air of ill deserved legitimacy, forgetting for a moment whether a few PEAR contributions make me any more deserving of a vote than others. No rule is being broken. The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the following: Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+ additional months) As Bob pointed out, what 'Line up' means - whether it means vote ends, vote begins, or discussion begins - is completely open to interpretation. I don't remember what I meant when I wrote it, but arguably, 'line up' is a lot closer to 'start discussing' than 'finish voting', and as is typically the case when something is unclear, the most lax interpretation is acceptable. By your own words: http://marc.info/?l=php- internalsm=142451267910615w=2 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. **votes to begin by March 15**. That was the interpretation you used a month ago. Anthony, I did not read my own words and therefore didn't notice an even more lax interpretation was possible. What you can see is that I always lean towards the lax interpretation, by my own words. The fact that this wasn't even brought as an option was an oversight, but doesn't change the fact that the timeline RFC doesn't mention anything about voting, but about lining up RFCs. Again, I don't pretend to remember what I meant when I wrote it - but I would say that if I intended for it to be related to voting - whether it's voting begins or voting ends - I would have likely wrote that explicitly in the RFC, instead of using the lax 'line up' term. If anybody is being political, it's people who try to use the timeline RFC - designed to get PHP 7 out the door as soon as possible - while in parallel denying a competing RFC to go to a vote on technicalities (it's not the same RFC), to be discussed at all due to other technicalities (you missed the deadline!), and at the same time suggest that there are voting irregularities, incidentally, among the people voting against their RFC. Anthony, in case you don't know, *that* is politics. Not putting an RFC to a vote. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls
Hi 2015-03-15 8:33 GMT-03:00 Dan Ackroyd dan...@basereality.com: On 15 March 2015 at 06:59, Marcio Almada marcio.w...@gmail.com wrote: Hi, I received some requests to update the RFC with more information about BC breaks + possible minor adjustments regarding dynamic function calls. Please can you stop abusing the RFC process? This RFC is attempting to change the language. You received the information about the BC breaks weeks ago, they aren't new items that you just heard about for the first time today.. You opened the voting and then closed it immediately when you realised the vote wasn't going to sail through. There is no abuse. This is not true, I truly received a suggestion from Bob Weiland and decided to consider it. 4:3 is not a sign that a voting will pass or not, it's only 7 votes and we usually get ~52 votes during a 14 days voting period. You're now making changes to the RFC and proposing to re-open voting on the same day. How are people meant to have time to read and think about the changes? It's a **minor** change, as said before. This was the most prudent attitude. It's also going to be impossible for people to try the patch out, or to measure it for performance hit. Performance has never been an issue with this RFC. You probably meant bc break not performance hit, and the suggested change about dynamic calls Bob did, if accepted by, is a minor change that will actually reduce the BC breaks not enlarge it. The problem this RFC fixes is not a big enough problem to justify making decisions about the language at the last minute, particularly as the last version of the RFC I read breaks a whole load of valid code. A lot of people tell me the opposite. I listened to your opinion many times and disagreed with it. Please don't express your disagreement with the RFC by mixing it with false accusations towards me. There is a huge gap between both attitudes. The disagreement is ok, but the false accusations coming from you make me sad. cheers Dan Marcio
Re: [PHP-DEV] [VOTE] Generator Delegation
Hi Daniel, In the formal definition, you have: $throw $e; ... which I assume is a typo? Damien On Sun, Mar 15, 2015 at 8:18 PM, Daniel Lowrey rdlow...@php.net wrote: Hi folks! As the discussion period has reached its conclusion I'd like to announce a two week voting period on the Generator Delegation RFC here: https://wiki.php.net/rfc/generator-delegation Voting ends Sunday, March 29. I know everyone is busy and your time is valuable; thanks for spending a few minutes to review the proposal. If you have any questions please don't hesitate to ask. -Daniel
Re: [PHP-DEV] [VOTE] Generator Delegation
On Sun, Mar 15, 2015 at 3:56 PM, Damien Tournoud d...@damz.org wrote: Hi Daniel, In the formal definition, you have: $throw $e; ... which I assume is a typo? Damien Woops! Yes, this is a typo. Thanks for the heads-up; fixing now ...
Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
On 15 March 2015 at 10:29, Matteo Beccati p...@beccati.com wrote: I want to vote yes, but naming is something that scares me a bit. Without any indication that it's CSPRNG, people might start using it even when unnecessary, and I'd be worried about potential negative effects, such as exhausting the entropy pool. It's probably more of a documentation problem, but we know many won't read the docs and a hint in the function name could help guiding users. I wouldn't worry about exhausting the entropy pool, on systems like Linux there is kind of a feedback system where data is mixed back into the pool when you request data. You can pipe /dev/urandom into /dev/null for hours and not suffer any problems. For example, it would be overkill to use random_int() to randomly pick the content of a boxes at each reload of a web page, but if what I need is a *random int*, then random_int() seems a far better choice than some obscure rand() or mt_rand(). Of course it would, but that's something that needs to be done through education and via the manual. I understand the concern, but I'm not sure how much I'll worry about it. Or in the poker deck example, wouldn't it be enough just to seed mt_srand with a crypto-secure number to remove the biasing and using mt_rand to shuffle the deck? The biasing comes from how the result is restricted to a certain range of numbers, it's not related to the quality of the seed. We avoid that by throwing away numbers that would give a biased result, and picking a new number. The poker deck example isn't a brilliant one, because the effects of biasing become more apparent the closer you get to the maximum upper bound, but it's still important to cater for the unlikely-but-possible scenarios.
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
I don't think agreeing to any of the three proposals out there is the best option. I personally think there are viable options out there that have not yet been heavily discussed. For instance, everyone and their dog has complained about PHP's overly promiscuous type juggling. This is one reason scalar types proposals are having issues; we don't want to have the same promiscuous type juggling on these scalar types so we are defining new rules. Instead, why don't we fix at least some of those conversions first? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
On 15 March 2015 at 13:17, Pádraic Brady padraic.br...@gmail.com wrote: Were folk to use random_int() by default, it would be actually be considerably better than the situation today where many reach for mt_rand() without really considering the use case. Using a strong source of ints instead of a weak source still ends up with you getting the requested ints. There's no downside unless the source is blocking. We've deliberately avoided blocking sources for this implementation. Using the weak source over a strong source will also get you ints, but without knowing the use, it has the immediate downside risk of being from a weak source which shouldn't be used for anything requiring strong randomness. So random_int() really is the best first default option to go for when in doubt, with some careful consideration before switching to mt_rand(). As for exhausting the entropy pool, this is something of a misconception. The sources in the RFC are pseudorandom generators which won't exhaust the entropy pool by design. I should have read your mail before replying, but at least we've said the same thing :)
Re: [PHP-DEV] [VOTE] Generator Delegation
Hi Daniel, Would you mind clarifying the relationship between the Generator Delegation RFC and the Generator Return Expressions RFC? While I really appreciate the Generator Delegation RFC, the Generator Return Expressions looks both unnecessary and kind of a hack to me. In evented system based on coroutine/generators (for example Python greenlet/gevent) the ability to return a value is handled higher up than the generator/coroutine itself, which has other advantages (like the ability to yield until the value is available, instead of simply throwing, etc...). Essentially, returning a value is an abstraction of the cooperative framework (usually an event loop), not of the generator itself. Damien On Sun, Mar 15, 2015 at 8:18 PM, Daniel Lowrey rdlow...@php.net wrote: Hi folks! As the discussion period has reached its conclusion I'd like to announce a two week voting period on the Generator Delegation RFC here: https://wiki.php.net/rfc/generator-delegation Voting ends Sunday, March 29. I know everyone is busy and your time is valuable; thanks for spending a few minutes to review the proposal. If you have any questions please don't hesitate to ask. -Daniel
Re: [PHP-DEV] [VOTE] Generator Delegation
2015-03-15 21:13 GMT+01:00 Damien Tournoud d...@damz.org: Hi Daniel, Would you mind clarifying the relationship between the Generator Delegation RFC and the Generator Return Expressions RFC? While I really appreciate the Generator Delegation RFC, the Generator Return Expressions looks both unnecessary and kind of a hack to me. In evented system based on coroutine/generators (for example Python greenlet/gevent) the ability to return a value is handled higher up than the generator/coroutine itself, which has other advantages (like the ability to yield until the value is available, instead of simply throwing, etc...). Essentially, returning a value is an abstraction of the cooperative framework (usually an event loop), not of the generator itself. I already wanted to ask why you voted no on return expressions. The reason for having delegation dependent on return expression is that coroutines can have a result that should be available just like any other function. $result = yield from coroutine(); Without return expressions, there would be no way to access the result of a coroutine. The relevant section in the RFC should be the following: https://wiki.php.net/rfc/generator-return-expressions#use-casecoroutine_return_values I hope that clarifies it, if not, please ask again. Regards, Niklas Damien On Sun, Mar 15, 2015 at 8:18 PM, Daniel Lowrey rdlow...@php.net wrote: Hi folks! As the discussion period has reached its conclusion I'd like to announce a two week voting period on the Generator Delegation RFC here: https://wiki.php.net/rfc/generator-delegation Voting ends Sunday, March 29. I know everyone is busy and your time is valuable; thanks for spending a few minutes to review the proposal. If you have any questions please don't hesitate to ask. -Daniel
Re: [PHP-DEV] [RFC][VOTE] In Operator
Hi Niklas, To reiterate and explain my no vote: The RFC is still lacking one thing - any justification of why this deserves being a new piece of syntax, rather than just being a function implemented either internally, or even better in userland PHP. The equation is not just will PHP be better with this instead it's will PHP so much better that it justifies the known cost of adding syntax to the language, as well as the unknown cost of blocking future use of the 'in' keyword. I'm sorry, but I just can't see that the value in adding this comes anywhere close to justifying it's addition. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
-Original Message- From: Philip Sturgeon [mailto:pjsturg...@gmail.com] Sent: Sunday, March 15, 2015 10:33 PM To: Zeev Suraski Cc: Nikita Popov; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types On Sun, Mar 15, 2015 at 4:23 PM, Zeev Suraski z...@zend.com wrote: Sorry, but ... even though your original RFC was very unclear about this, everybody went by the all votes must start by the 15th interpretation that has been discussed in that thread. Do you think it's an accident that a whopping six RFC votes started today? It isn't. Please don't start reinterpreting things to fit your needs. I am personally totally fine with extending the PHP 7 timeline by say one month - but if we do that, let's make it official and applying to everyone, not just some particular RFC. I know for sure that there are a number of additional RFCs that would have been submitted for PHP 7 had anyone known that it'll be allowed. First off, this is Bob's interpretation which he brought up on Friday. Yes, ideally I would have read the original text during the discussion period and commented on it, but I didn't. I think the 3 month period for implementation (that's mostly done) and testing gives a very reasonable time period to absorb the most lax of interpretations. I think it would be a shame to delay the timeline for this, but I also think it would be a shame for the timeline - that was *clearly* not designed to create de-facto bias towards one RFC or the other - to do exactly that. Even if we were to push the timeline out by a bit, how do we do it? An RFC with a minimum discussion period of two weeks and another week for a vote? That kind of defeats the purpose. A gentlemen's agreement? Something else? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Even if we were to push the timeline out by a bit, how do we do it? This is ~My approach hasn't won yet, and instead of conceding default due to democracy in action, I would like to change the process. I am not insulting you. I am not attacking you. But this is some bizarre stuff that is more than sneaky, and you really need to stop. Phil, Do you mind STOPPING TO TWIST THINGS TO FIT YOUR AGENDA, please? And no, saying you don't insult me or attack me after doing exactly that does not change anything. It's NIKITA that proposed this. It's BOB that proposed the lax (and very reasonable) interpretation to the Mar 15 timeline. Why did you not 'not insult' and 'not attack' them? Is it open season on Zeev only? One RFC has won. Another RFC has lost. A third RFC is a backup plan and nothing more. None won and none lost as of yet. Are there some special rules for a backup plan anywhere in the Voting RFC or the Timeline RFC that I missed? Or are you allowed to make those up? How sneaky of you. And bizarre. But no worries, I'm not insulting or attacking you! *THIS* is toxic. If Nikita brings up a point, I ask him to elaborate a bit, and you jump on me (as you did numerous times over the last month) - this is unacceptable. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static constructor
Am 15.03.2015 um 19:47 schrieb Rowan Collins:
On 15/03/2015 10:41, Johannes Ott wrote:
Okay get your point, but as already discussed several times, the rfc
should not be declined for the reason a ppl, who doesn't understand when
to use static context or when not to use at all, can do crucial things.
Because he although can do without the static constructor.
For a horiffic example:
class Example {
private static $handler;
public function open() {
self::$handler = fopen('example.txt');
}
...
}
Example::open();
Indeed I have the opinion some beginner who is doing such horiffic code
maybe think more about what he is doing and especially about the side
effects inside a so called magic method, then outside.
I'm not clear what's so different between this and your logger example.
Here you have a file handle, which in PHP happens to be a special type
rather than an object, and are storing it in a static property; closing
the file handle has to be managed somehow, and this code is letting PHP
do this implicitly with what amounts to a destructor on the file handle
resource.
The difference is as I told the Resource Handler is wrapped inside a
Singleton Instance with a destructor!
I never ever would store any kind of resources (opening any kind of
connections to db, file, socket etc.) directly to the static context
without wrapping in a instance, because those are really dynamic handles
which need a proper constructor and destructor for the special
connection.
However many intermediate instances you create, at some point the
destructor has to run, and that will only happen once the static
reference is unset. Luckily, the Zend Engine will go through and garbage
collect all global and static variables at the end of a request, so you
can cheat that way.
I think that is no kind of a cheat, in my opinion this is the normal
behavior how static stored properties and instances, stored at them,
should be cleanup in every oop-language.
Or, you can *invalidate* the objects, rather than destructing them, as
implied by your DBAdapter::closeAllConnections() example - there will
still be references to those connections live in your code if, for
instance, you have Example::$logger, and $logger-dbConnection. You
can't have an Example::cleanupResources() method, because it would fire
the static constructor on pages which hadn't used the class yet,
destroying the lazy-loading.
You always talking about the singleton-pattern, as I although told
different times now, I have no resources directly stored in static
context but in singleton instances inside.
for example the DBAdapter::closeAllConnections():
public static closeAllConnections() {
while(count(self::$connections) 0) {
self::$connections[0]-close();
unset(self::$connections[0]);
}
}
the same for LogAdapter.
What you're really relying on is that the implicit static destructor
provided by the engine is good enough for the kinds of resource which a
static constructor should be dealing with. This is also true of many
objects, which don't technically need a custom destructor to close file
or DB handles, because Zend will reference count the resource, but more
advanced objects can do more advanced cleanup.
Yes indeed this is true, and again same sentence: resources - inside
instances not directly inside static property.
Regards,
--
DerOetzi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Voting irregularities
-Ursprüngliche Nachricht- Von: Matthew Leverton [mailto:lever...@gmail.com] Gesendet: Sonntag, 15. März 2015 20:46 An: Anthony Ferrara Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] Voting irregularities On Sun, Mar 15, 2015 at 9:19 AM, Anthony Ferrara ircmax...@gmail.com wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. ... Something that I think we need to discuss as a group. So consider that discussion open. I think this is likely because the votes are made public during voting phase. To me, that is a bad thing. It makes for an ugly voting period. That sort of politics should happen during the discussion phase. So I don't think there's anything wrong with first time voters voting No en masse here. I just think there's a major problem in having a real-time count of votes during the voting period. If votes weren't made public during the voting, then more people would vote on more issues... avoiding this situation where people come from nowhere to cast a vote as word gets out on blogs that something terrible is about to happen. In short, I think the real-time public vote results causes a few problems: 1) Bandwagon voting, or vote for the winner mindset. The early wave of voters can impact the results by discouraging people from voting. (Look at Zeev's RFC vote count vs Anthony's.) 2) The losing side feverishly drumming up votes, often with scare tactics - i.e., vocal minority. (It's much easier for the No side of any vote to appeal to this.) 3) In rare cases, Gaming the system - closing the vote at the exact time that benefits the owner of the RFC. So I don't think there's anything sinister here. It's just the natural result of the voting rules. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I agree with Matthew here, the voting process should be revised and votes should not be public -- for anyone -- until closed. I mean, every sane democratic country is using the secret ballot method, why shouldn't PHP use it? But I am not a voter, so just my 2 cents Cheers, Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On 3/15/15 10:19 AM, Anthony Ferrara wrote: [...] The following voters never voted before the dual-mode RFC went up: [...] eliw - no [...] Some of these names I recognize from list (sammywg and eliw), but many I do not. [...] I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. I think it does raise a significant question around the voting practices. Hello Anthony ... given I was 'called out' here I figured I should respond. My vote (and the situation around it) is exactly what people have assumed. That is: 1. I've long been a member (prominent by some people's definitions) of the PHP Community 2. I've long been a member of Internals, and read everything, and at times join the discussion when I feel I have something to contribute. (If I don't, then I don't clutter the list - there's enough clutter and enough amazingly smart people on this list, like both you and Zeev, that I'm content to read the excellent discussions) 3. I was long (long) ago offered an acct to have a vote, and actually declined because I didn't feel it warranted. 4. A while ago, I ended up getting an acct anyway, because I started helping out with the documentation/webmaster/calendar stuff which noone else was doing 5. I still never used my vote, on any issues, even the PHP 7 one which I was one of the main instigators of. Because I, like Padraig, kinda was in that mentality that I shouldn't use it. And that I would wait, until there was a proposal that I felt very strongly about, and where my vote/my voice could make a difference. To cast my vote. And so in this case, my first case. I did cast a vote. And unfortunately I have received no end of private (and some public) flak about said vote. And while I know that you are just looking at numbers and being open about 'Hey this is interesting lets chat about this'. Others have not been so kind. FWIW - I would always assume the best of people - And I would assume that others on that voting list in fact were in similar situations. Where they hadn't voted before simply because they didn't feel they felt strongly enough about something. Also this is the first 'on the edge' hyper-contentious vote in quite a while, which means that lurkers are much more likely to have it come to their attention that this vote is happening, and therefore that they should familiarize themselves with it and cast a vote. As to why so many of those 1st time voters, who have decided their vote is worthwhile, happen to be voting no more often than not. Well I have other theories on that (which do not include any negative consequences or foul play, but simple cases of human mentality and 'community' vs 'community' discussions) In service to PHP, Eli -- | Eli White | http://eliw.com/ | Twitter: EliW | signature.asc Description: OpenPGP digital signature
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. Why am I making this admittedly big move? I think that waiting until we know for certain whether the Dual Mode STH would win is very problematic, for two reasons. The bigger one that it runs a serious risk we have no STH at all for 7.0. It's not an unlikely scenario either - it's probably 50/50% that the Dual STH RFC would fail, only to find later - when it's too late - that Strict campers have enough votes to block the Basic one. Personally, I find that the worst possible outcome, given how clearly it is that the users at large want *something*. If the Basic RFC is put to a vote but retracted if when we see it stands no chance to pass - combined with my commitment to support the Dual STH in such a case (and my belief that move will be able to influence others as well), the chances that we'd be left with no STH at all for 7.0 goes down significantly. There's also a secondary reason - I do think it's unfair that in a very likely scenario - we won't be giving people who prefer Basic STH only - at least at this point - a chance to vote at the proposal they think is best. I don't think it's a matter of voting for who's going to win; In fact with a commitment to retract it if it fails to win, it's not about that at all. It's being able to vote for what you truly believe in, as opposed to a compromise that you find bad but better than nothing. And in my case (and perhaps others) - it's about being willing to vote for something I actually don't believe it at all for the sake of unity, but only once the alternative options have been explored. Before Dual STH supporters dissect my move to pieces, please realize this: If you're right - that Basic STH stands no chance to gain 2/3 majority - you have absolutely NOTHING to lose, and in fact, you're increasing your chances of passing that vote through from apparently 50/50 to 80/20 (not talking about votes, but chances), and as a bonus, you get to prove your point. If you're wrong - and Basic STH is more popular than Dual STH (at this point in time) - we would have given the community at large something that's closer to what it really wants. Zeev -Original Message- From: Bob Weinand [mailto:bobw...@hotmail.com] Sent: Sunday, March 15, 2015 5:51 PM To: PHP Internals Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar Types Hey, to clarify what the way to go with this RFC is. This RFC is a FALLBACK. It's about the common part of both other RFCs. That way it *only* will go to vote after Anthonys RFC ends. And *only* if it fails. That means, I will go by the voting RFC and wait until discussion period ends and put it to vote after Anthony closes his RFC in case it fails. I'm aware that a few people have said, they will change their vote depending on what ever might pass. And that they asked for this RFC going into direct competition against Anthonys RFC. No. Know what you want. If you dislike Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't switch your votes back and forth depending on what might win. That's why I decided to not have the vote on this running concurrently with Anthonys. But, in any case this RFC will go to vote on the 24th if Anthonys RFC couldn't gather a 2/3 supermajority. Thanks, Bob -- 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
[PHP-DEV] Re: Voting irregularities
Hi all, since my handle was included in the list compiled by Anthony, I figured I'd reply to internals list as well. On So, 2015-03-15 at 10:19 -0400, Anthony Ferrara wrote: I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. You may not recognize my account but I sure hope you recall speaking to me in person before. You even attended one of my talks at Confoo last year.. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: I cannot speak for anyone else, but I indeed didn't actively vote before. I honestly though don't recall if me voting on this RFC was my first vote or not. I also voted on other RFCs though. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. Since sounds awfully like 2nd class voting. And, would you ask for the same if the situation would be reversed? I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. Why would you calculate the alternative result then? I think it does raise a significant question around the voting practices. Something that I think we need to discuss as a group. Again, I can't speak for others but only myself. I decided to vote on this RFC as well as some others since I believe my experience and expertise might qualify. I didn't (and don't) vote on anything where I feel I don't fully oversee the consequences or can judge the impact. And because I think the RFCs I voted on are important. Quite often before, I discussed things with others - for instance with Sebastian Bergmann -, who then posted the results of our thoughts on internals or talked to others on IRC to get more feedback. Last that happened with the idea of providing the throwable interface as an addition to the engine exceptions and in favor of the base exception class. Either way, I mostly only passively read on internals. I prefer talking to people in person, or if there is no timely alternative on chat. For what it's worth: I do have a php.net account since 2001, mostly working on the German translation of the docs. If that and my general visibility in the community entitles me to add my vote here is something others have to judge. I honestly can't say. But having my vote ignored (or at least considered questionable) because it tends to sway the RFC results in the wrong direction feels really odd. Regards, Arne -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer,1987) signature.asc Description: This is a digitally signed message part
Re: [PHP-DEV] [RFC] Basic Scalar Types
On Sun, Mar 15, 2015 at 6:48 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev,
Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.
So we are either violating the RFC rules by pushing the vote tomorrow or
we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?
Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail and
introduced well over two weeks ago.
I hope we're not going to go into more and more extremes of playing a law
firm and not an OS project.
We have minimum discussion periods for a reason. To allow people the
time to review proposals as much as to discuss them.
On the surface, yes, this looks like Andrea's 0.1 RFC. However, after
looking at it, it's definitely different. There's a very significant
behavior difference between the two:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be
consistent with our existing type hints for classes, callables and arrays,
NULL is not accepted by default, unless the parameter is explicitly given a
default value of NULL. This would work well with the draft Declaring
Nullable Types RFC.
This proposal has a different behavior here. It explicitly allows
nulls for types:
function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.
This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.
So it's not effectively the original proposal. It does differ in a
very significant detail. This is why we have mandatory discussion
periods. Not for playing law firm but for being fair to each other.
Anthony.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
good catch. Nullable RFC would IMHO help PHP, and underminding it isn't good.
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Basic Scalar Types
On Sun, Mar 15, 2015 at 12:03 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmax...@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be
consistent with our existing type hints for classes, callables and arrays,
NULL is not accepted by default, unless the parameter is explicitly given a
default value of NULL. This would work well with the draft Declaring
Nullable Types RFC.
This proposal has a different behavior here. It explicitly allows
nulls for types:
function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.
This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.
Anthony.
Anthony,
I think you've got something wrong there. It won't undermine an attempt at a
nullable RFC.
In the weak scalar typing world, nullables won't change what we accept, but
what we receive.
function (int|null $abc) { var_dump($abc); }
(or ?int or whatever syntax we will use)
would allow null to *not* be casted here.
Means foo(null) will lead to $abc being null and not int(0) with that
signature.
I think allowing `null` for an `int` is an error. Converting a null to
zero on a type boundary is harmful in my opinion.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Basic Scalar Types
On Sun, Mar 15, 2015 at 2:16 PM, Niklas Keller m...@kelunik.com wrote: 2015-03-15 19:13 GMT+01:00 Levi Morrison le...@php.net: I think allowing `null` for an `int` is an error. Converting a null to zero on a type boundary is harmful in my opinion. I agree, `null` shouldn't be allowed for `int`. -- 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 And this stuff is why we have minimum discussion periods, instead of just trying to smash an RFC through because it resembles a version that we liked a while ago. The Basic STH RFC should go to vote - as Bob has said a few times - if the Dual STH fails. Please do not try and take it over Zeev. It's reckless, and feckless. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG
On Sun, Mar 15, 2015 at 11:29 AM, Matteo Beccati p...@beccati.com wrote: On 15/03/2015 04:23, Sammy Kaye Powers wrote: A two week discussion period has been held for the reliable user-land CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now been moved into voting. https://wiki.php.net/rfc/easy_userland_csprng There was some discussion of prefixing the function names with `crypto_*()` but there are a few reasons we decided against this: 1) There is a crypto pecl extension, so the pseudo-namespace might cause confusion. 2) We want to work on a fully featured crypto framework for 7.1, and crypto_* is a good prefix for that, so again, we don't want to mix things up. [...] Or in the poker deck example, wouldn't it be enough just to seed mt_srand with a crypto-secure number to remove the biasing and using mt_rand to shuffle the deck? The problem is that when using mt_rand - even if you seeded it with a cryptographic random number - you will be able to predict all future random numbers based on the first few. The tiny 32bit seed space can be easily brute forced. MT also allows directly recovering the full internal state from the output, though that requires a relatively large amount of values (624 if not truncated) and as such isn't practical for the Poker case. Nikita
RE: [PHP-DEV] Voting irregularities
-Original Message- From: Philip Sturgeon [mailto:pjsturg...@gmail.com] Sent: Sunday, March 15, 2015 6:31 PM To: Zeev Suraski Cc: Levi Morrison; Michael Wallner; internals@lists.php.net Subject: Re: [PHP-DEV] Voting irregularities Literally nothing Anthony said was ridiculous or a conspiracy theory. Phil, I disagree. 'New' voters voting sharply in favor of No strongly implies some sort of foul play. Why break it down otherwise? I'm not saying that all of these votes are bad is equivalent to saying I am saying that some of these votes are bad. It's further strengthened by providing numbers of where this RFC would be at if these votes were discounted, as if it's on the table (that, I would argue, is the ridiculous part). Also, it really doesn't matter what you or I think about it. What matters is what everyone thinks about it. We already have one person understanding this email as a reason to look into when these accounts were created, and judging from the Twitter messages, he's not alone in suspecting some sort of foul play. I absolutely do think we should revisit our voting practices, but absolutely not in the context of a specific RFC, and not mid-flight. The quiet period after PHP 7's RFCs close could be an appropriate time for that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Basic Scalar Types
Zeev,
Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.
So we are either violating the RFC rules by pushing the vote tomorrow or
we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?
Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail and
introduced well over two weeks ago.
I hope we're not going to go into more and more extremes of playing a law
firm and not an OS project.
We have minimum discussion periods for a reason. To allow people the
time to review proposals as much as to discuss them.
On the surface, yes, this looks like Andrea's 0.1 RFC. However, after
looking at it, it's definitely different. There's a very significant
behavior difference between the two:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be consistent
with our existing type hints for classes, callables and arrays, NULL is not
accepted by default, unless the parameter is explicitly given a default value
of NULL. This would work well with the draft Declaring Nullable Types RFC.
This proposal has a different behavior here. It explicitly allows
nulls for types:
function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.
This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.
So it's not effectively the original proposal. It does differ in a
very significant detail. This is why we have mandatory discussion
periods. Not for playing law firm but for being fair to each other.
Anthony.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
-Original Message- From: Pavel Kouřil [mailto:pajou...@gmail.com] Sent: Sunday, March 15, 2015 7:52 PM To: Zeev Suraski Cc: Bob Weinand; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types I like your idea, but there's a problem with this (apart from the thing that it's not supposed to be in vote for 7.0 if you go by the rules, based on opinion of some people here). You are saying we would have given the community at large something that's closer to what it really wants, but the people maintaining PHP vote on that, not the community and userland developers (and that's a problem with most of the features here, that the direction in which PHP evolves is basically chosen by C programmers*). That is factually incorrect. C coders are a small minority amongst the voters on this RFC - you can check it yourself by clicking on each voter and seeing what Karma they have. Also, the majority of C contributors also develop or developed in PHP as well (myself included). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
C'mon guys, vote didn't pass, it's time to do something about it and not start conspiracy theories (or I will loose hope for humanity completely). I happened to have a job-free next week, i've been saying for a long time now that this has to be tackled differently and even layed down some thoughts on this. I do not think this can be done in single RFC, too much things to handle, too much things are left out, many things are ignored by the RFC people. What we need, is a MANAGER! To manage the Type Hint development. And one that is not doing real development on PHP core, but someone with understanding. I can offer myself at this point. I do not really care if thouse would be strict or coercive type hints as long as it's not the dual mode stuff.
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Zeev, Thus, I deny your request and strongly urge you to *not* fork my RFC. That would be sabotaging of Anthony's and my RFC. I won't tolerate that. Anthony welcomed competing RFCs, and in fact proposed it. I don't see how it would be sabotaging your RFC - when in fact it gives it a chance to pass in a case Dual Mode manages to garner. I welcomed competing RFCs according to the accepted process **a month ago** (http://marc.info/?l=php-internalsm=142383869529695w=2). I even extended voting on my RFC as a show of good faith. Please don't abuse that good faith to political ends. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
2015-03-15 20:55 GMT+02:00 Levi Morrison le...@php.net: What we need, is a MANAGER! To manage the Type Hint development. And one that is not doing real development on PHP core, but someone with understanding. You are basically saying we should hand development of a critical language feature over to someone not doing real development on the language. I don't see how that could possibly end well. I'm saying you need a manager to orginize the process, and as I see it, make it a multi-version effort, like the OOP has evolved. Well, I probably over-generalized. It has to be atleast a userland developer with good amount of PHP development experiense under his/her belt to understand, he needs to have patiense, and above all, he needs to discipline himself on amount of writing and replying, otherwise it will get messy again. It can be a core dev too, it's just from what I have seen, people push their own agenda too much when they are the developer behind the RFC. It's good over all, but I think this paticular case is an exception. And based on how long the type hints are taking to get anywhere, I say it needs some special handling. Type hints mutated over time from a simple proposal into something big, over-engeneered and over-agressive. I have never seen a feature so complex being done in a single go into PHP since i'm folowing internals list, and that's since late days of PHP4... So, long story short: I suggest we restructure the effort and have someone impartial at the helm mediating the work being done, draw some lines and execute a plan people can agreee on.
[PHP-DEV] Just a test (feel free to ignore/delete)
Hope everyone is having a good weekend, just making sure my outbound emails are registering on the list :) -- Mike Dugan m...@dugan.io http://dugan.io
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Sunday, March 15, 2015 9:22 PM To: Zeev Suraski Cc: PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types Voting for something you don't think is right isn't unity. It's simply trying to make yourself look good. I don't think you understand the meaning of unity, but I'll let internals be the judge of that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
Which post says that we're turning PHP into Java I think there are people who want to switch from Java to PHP, maybe they feel easier with declare(strict...). Also in the past, some companies switched from PHP to Java because they wanted more strictness in their backend code. I don't like declare(strict...), but we should give it a chance in practice and then every userland developer can decide on his own if his programming style fits to it, or not. For me personally, I must admit that I am not using namespaces, traits and goto, but almost all other features of PHP :) Regards Thomas Derick Rethans wrote on 15.03.2015 20:07: Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015 17:59:17 GMT+00:00: On 15/03/2015 14:19, Anthony Ferrara wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. I think calling this an irregularity is going a bit far. I don't think it's going to far, if you have people with no clue writing this: https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB Which post says that we're turning PHP into Java. And to this misguided FUD post, that actively asks people to vote no, I can quite easily attribute a few more no votes of people that had never voted before... Too late to tighten up the rules for this one, but something is definitely not right with the current process. Cheers, Derick -- http://derickrethans.nl | http://xdebug.org twitter: @derickr and @xdebug -- 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] Generator Delegation
On Sun, Mar 15, 2015 at 4:39 PM, Damien Tournoud d...@damz.org wrote: On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey rdlow...@php.net wrote: This is actually a *vastly* inferior solution to language-level support for generator returns. greenlet/gevent does it this way because these libraries were created before Python supported generator delegation (and continue supporting Python 2.5). When you have generator returns you don't need any of that additional cruft. Instead, a language supporting generator returns can simply yield promises (or whatever concurrency primitive you prefer). Period. Hi Daniel, I actually disagree here. Using generators as coroutine is a hack, and is vastly inferior to having actual coroutine support in the language, but obviously we do what we can with the language we have. (Yes, I am in the camp that *really* dislike explicit yielding.) I do understand where this is coming from, so changing my vote to yes on the other RFC. Damien I can appreciate your viewpoint :) We do what we can with the tools we have at our disposal. If you don't want to see it happen then I can live with that. It is, my job, as the RFC author to persuade people. Thanks for your honest input!
Re: [PHP-DEV] Voting irregularities
Can we please stop with this? It's damaging to the language and the community. I am a strong believer of STH, no surprise there, but I do not think this thread should have been created. Is the php voting process uncontrolled and chaotic with no real count of voting members? Hell yes. This does not mean by far that this is the right time to discuss this. Let the RFCs go their way and once feature freeze is in and no more RFCs popping up for a while, the process can be discussed and optimised, if the case may be. All in all STH has turned into this big charade, and no matter which way it goes someone, there are going to be a lot of future friction and told you so's. In terms of managers, we do have a release manager, stick to that for the 7.0 release, re-evaluate after. My 2 cents, Stelian On Sun, Mar 15, 2015 at 8:56 PM, Thomas Bley ma...@thomasbley.de wrote: Which post says that we're turning PHP into Java I think there are people who want to switch from Java to PHP, maybe they feel easier with declare(strict...). Also in the past, some companies switched from PHP to Java because they wanted more strictness in their backend code. I don't like declare(strict...), but we should give it a chance in practice and then every userland developer can decide on his own if his programming style fits to it, or not. For me personally, I must admit that I am not using namespaces, traits and goto, but almost all other features of PHP :) Regards Thomas Derick Rethans wrote on 15.03.2015 20:07: Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015 17:59:17 GMT+00:00: On 15/03/2015 14:19, Anthony Ferrara wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. I think calling this an irregularity is going a bit far. I don't think it's going to far, if you have people with no clue writing this: https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB Which post says that we're turning PHP into Java. And to this misguided FUD post, that actively asks people to vote no, I can quite easily attribute a few more no votes of people that had never voted before... Too late to tighten up the rules for this one, but something is definitely not right with the current process. Cheers, Derick -- http://derickrethans.nl | http://xdebug.org twitter: @derickr and @xdebug -- 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] [RFC] Basic Scalar Types
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmax...@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be
consistent with our existing type hints for classes, callables and arrays,
NULL is not accepted by default, unless the parameter is explicitly given a
default value of NULL. This would work well with the draft Declaring
Nullable Types RFC.
This proposal has a different behavior here. It explicitly allows
nulls for types:
function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.
This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.
Anthony.
Anthony,
I think you've got something wrong there. It won't undermine an attempt at a
nullable RFC.
In the weak scalar typing world, nullables won't change what we accept, but
what we receive.
function (int|null $abc) { var_dump($abc); }
(or ?int or whatever syntax we will use)
would allow null to *not* be casted here.
Means foo(null) will lead to $abc being null and not int(0) with that signature.
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
-Original Message- From: Bob Weinand [mailto:bobw...@hotmail.com] Sent: Sunday, March 15, 2015 7:51 PM To: Zeev Suraski Cc: PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types Zeev, I'm sure we risk to have no STH at all in PHP 7.0 if I put it into vote now. Some people will change their vote, not enough people for basic to pass. Also, I definitely won't support going back and forth with the votes. If you have issues with dual mode, vote against it. If you like the Basic Types RFC, vote in favor of it, once it starts. You're all given a chance. I don't view this as a purely technical vote, and I don't think our community does either. It goes well beyond technology - if we fail to add STH in 7.0, it will be perceived as a major disappointment for the userbase and supposed proof that the project is unable to reach decisions. The plan you propose greatly increases the danger of that, because we have zero visibility into how people would vote. Clearly, a lot of people here disagree with you about the concept of going back forth on votes. They view it as fair and warranted under the current situation, where we don't have a better way of resolving a conflict between competing RFCs. The availability of the Basic option will affect the vote on Dual Mode, they're not independent. It's not ideal, but that's the mechanism we have for now. We should have a version of STH we have *consensus* on, not some type of STH most people dislike, just for the sake of it. Please respect my stance on that. I agree, except it's not an option with the plan you propose. None of these proposals is going to have consensus, in the accepted sense (an idea or opinion that is shared by all the people in a group, according to Meriam Webster). The Dual Mode STH, if it wins, will still have more 'no' voters than 'yes' votes casted for almost every other RFC. It will be a majority - a special majority - but very far from consensus. I'm also not at all sure that the Basic STH RFC - if you put it to a vote - will win something that's close to consensus. In fact, the only scenario where I see a chance for something that's closer to consensus is if we try to put the Basic out to a vote; On one scenario, we may see that a lot more people prefer Basic to Dual, and do the community a big service. On the other scenario - we'd see that it does nothing but further split the vote, retract it, and unite behind Dual. Whichever direction it takes - our chances of hitting something close to consensus goes significantly higher. Thus, I deny your request and strongly urge you to *not* fork my RFC. That would be sabotaging of Anthony's and my RFC. I won't tolerate that. Anthony welcomed competing RFCs, and in fact proposed it. I don't see how it would be sabotaging your RFC - when in fact it gives it a chance to pass in a case Dual Mode manages to garner. You had a time to do this RFC, but you did coercive. Correct, as I knew that Basic STH was strictly opposed by a lot of strict campers, and wanted to try to come up with a solution that would cater to both camps' needs. Going with Basic would have been easiest, but I thought it could reach something much closer to consensus - and failed. Reproposing Andrea's v0.1 RFC definitely came to my mind, but I did not recall the language in the Timeline RFC effectively allowing for RFCs to be proposed until the 15th until you brought it up. Does it make sense to you that the community may be barred from voting on this extremely important topic because you proposed it but refuse to put it to a vote? Now, it's my move with this RFC and not yours. Please accept that and don't play against us. Despite what I said, I am going to think about this hard. Still 3:15 hours of March 15th on this part of the planet. At the same time - I urge you to also think hard about it and reconsider, and put it to a vote as soon as allowed for the reasons mentioned above and in my previous post. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static constructor
On 15/03/2015 10:41, Johannes Ott wrote:
Okay get your point, but as already discussed several times, the rfc
should not be declined for the reason a ppl, who doesn't understand when
to use static context or when not to use at all, can do crucial things.
Because he although can do without the static constructor.
For a horiffic example:
class Example {
private static $handler;
public function open() {
self::$handler = fopen('example.txt');
}
...
}
Example::open();
Indeed I have the opinion some beginner who is doing such horiffic code
maybe think more about what he is doing and especially about the side
effects inside a so called magic method, then outside.
I'm not clear what's so different between this and your logger example.
Here you have a file handle, which in PHP happens to be a special type
rather than an object, and are storing it in a static property; closing
the file handle has to be managed somehow, and this code is letting PHP
do this implicitly with what amounts to a destructor on the file handle
resource.
I never ever would store any kind of resources (opening any kind of
connections to db, file, socket etc.) directly to the static context
without wrapping in a instance, because those are really dynamic handles
which need a proper constructor and destructor for the special connection.
However many intermediate instances you create, at some point the
destructor has to run, and that will only happen once the static
reference is unset. Luckily, the Zend Engine will go through and garbage
collect all global and static variables at the end of a request, so you
can cheat that way.
Or, you can *invalidate* the objects, rather than destructing them, as
implied by your DBAdapter::closeAllConnections() example - there will
still be references to those connections live in your code if, for
instance, you have Example::$logger, and $logger-dbConnection. You
can't have an Example::cleanupResources() method, because it would fire
the static constructor on pages which hadn't used the class yet,
destroying the lazy-loading.
What you're really relying on is that the implicit static destructor
provided by the engine is good enough for the kinds of resource which a
static constructor should be dealing with. This is also true of many
objects, which don't technically need a custom destructor to close file
or DB handles, because Zend will reference count the resource, but more
advanced objects can do more advanced cleanup.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
On 15 March 2015 at 16:55, Zeev Suraski z...@zend.com wrote: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. No one individual has the right to break the existing rules around voting. There has been more than sufficient time to date to rewrite the voting rules, debate voting rights, extend PHP7's deadline, or propose the basic RFC so described. A vote in contravention of the voting rules at the last possible minute cannot, by definition, be recognised at this time. I wouldn't even vote since it might lend it an air of ill deserved legitimacy, forgetting for a moment whether a few PEAR contributions make me any more deserving of a vote than others. I recognise that the rules are inconvenient in the current situation when time is in short supply, but that is why we have rules to offset the temptation of doing things considered socially unacceptable. They were voted on, they were adopted, and they remain adopted. There is only one way in which they may be unadopted. Another RFC. Yes, PHP, this is a government bureaucracy at work ;). I'm not a lawyer, and I wouldn't appreciate the intended spirit of the rules. Unfortunately, we don't have judges or juries, so all we can do is abide by the letter of the rules as written, a contract all of us have with the PHP community. Is that a perfect approach? Hell, no. What is? It's just the only approach we can possibly follow on Sunday, March 15th. If this RFC enters into voting in any time period not allowed within the rules as they are written, I will obviously not recognise it as valid in any way. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
-Original Message- From: Pádraic Brady [mailto:padraic.br...@gmail.com] Sent: Sunday, March 15, 2015 9:00 PM To: Zeev Suraski Cc: Bob Weinand; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types On 15 March 2015 at 16:55, Zeev Suraski z...@zend.com wrote: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. No one individual has the right to break the existing rules around voting. There has been more than sufficient time to date to rewrite the voting rules, debate voting rights, extend PHP7's deadline, or propose the basic RFC so described. A vote in contravention of the voting rules at the last possible minute cannot, by definition, be recognised at this time. I wouldn't even vote since it might lend it an air of ill deserved legitimacy, forgetting for a moment whether a few PEAR contributions make me any more deserving of a vote than others. No rule is being broken. The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the following: Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+ additional months) As Bob pointed out, what 'Line up' means - whether it means vote ends, vote begins, or discussion begins - is completely open to interpretation. I don't remember what I meant when I wrote it, but arguably, 'line up' is a lot closer to 'start discussing' than 'finish voting', and as is typically the case when something is unclear, the most lax interpretation is acceptable. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Generator Delegation
Hi folks! As the discussion period has reached its conclusion I'd like to announce a two week voting period on the Generator Delegation RFC here: https://wiki.php.net/rfc/generator-delegation Voting ends Sunday, March 29. I know everyone is busy and your time is valuable; thanks for spending a few minutes to review the proposal. If you have any questions please don't hesitate to ask. -Daniel
[PHP-DEV] [RFC][VOTE] In Operator
Morning, I just opened the vote for the in operator, you can find the RFC here: https://wiki.php.net/rfc/in_operator Vote will be open for two weeks, counting from today. Regards, Niklas
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
On Sun, Mar 15, 2015 at 8:21 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Sunday, March 15, 2015 9:11 PM To: Zeev Suraski Cc: Pádraic Brady; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types Zeev, On Sun, Mar 15, 2015 at 3:07 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pádraic Brady [mailto:padraic.br...@gmail.com] Sent: Sunday, March 15, 2015 9:00 PM To: Zeev Suraski Cc: Bob Weinand; PHP Internals Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types On 15 March 2015 at 16:55, Zeev Suraski z...@zend.com wrote: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. No one individual has the right to break the existing rules around voting. There has been more than sufficient time to date to rewrite the voting rules, debate voting rights, extend PHP7's deadline, or propose the basic RFC so described. A vote in contravention of the voting rules at the last possible minute cannot, by definition, be recognised at this time. I wouldn't even vote since it might lend it an air of ill deserved legitimacy, forgetting for a moment whether a few PEAR contributions make me any more deserving of a vote than others. No rule is being broken. The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the following: Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+ additional months) As Bob pointed out, what 'Line up' means - whether it means vote ends, vote begins, or discussion begins - is completely open to interpretation. I don't remember what I meant when I wrote it, but arguably, 'line up' is a lot closer to 'start discussing' than 'finish voting', and as is typically the case when something is unclear, the most lax interpretation is acceptable. By your own words: http://marc.info/?l=php- internalsm=142451267910615w=2 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. **votes to begin by March 15**. That was the interpretation you used a month ago. Anthony, I did not read my own words and therefore didn't notice an even more lax interpretation was possible. What you can see is that I always lean towards the lax interpretation, by my own words. The fact that this wasn't even brought as an option was an oversight, but doesn't change the fact that the timeline RFC doesn't mention anything about voting, but about lining up RFCs. Again, I don't pretend to remember what I meant when I wrote it - but I would say that if I intended for it to be related to voting - whether it's voting begins or voting ends - I would have likely wrote that explicitly in the RFC, instead of using the lax 'line up' term. Sorry, but ... even though your original RFC was very unclear about this, everybody went by the all votes must start by the 15th interpretation that has been discussed in that thread. Do you think it's an accident that a whopping six RFC votes started today? It isn't. Please don't start reinterpreting things to fit your needs. I am personally totally fine with extending the PHP 7 timeline by say one month - but if we do that, let's make it official and applying to everyone, not just some particular RFC. I know for sure that there are a number of additional RFCs that would have been submitted for PHP 7 had anyone known that it'll be allowed. Nikita
RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Sorry, but ... even though your original RFC was very unclear about this, everybody went by the all votes must start by the 15th interpretation that has been discussed in that thread. Do you think it's an accident that a whopping six RFC votes started today? It isn't. Please don't start reinterpreting things to fit your needs. I am personally totally fine with extending the PHP 7 timeline by say one month - but if we do that, let's make it official and applying to everyone, not just some particular RFC. I know for sure that there are a number of additional RFCs that would have been submitted for PHP 7 had anyone known that it'll be allowed. First off, this is Bob's interpretation which he brought up on Friday. Yes, ideally I would have read the original text during the discussion period and commented on it, but I didn't. I think the 3 month period for implementation (that's mostly done) and testing gives a very reasonable time period to absorb the most lax of interpretations. I think it would be a shame to delay the timeline for this, but I also think it would be a shame for the timeline - that was *clearly* not designed to create de-facto bias towards one RFC or the other - to do exactly that. Even if we were to push the timeline out by a bit, how do we do it? An RFC with a minimum discussion period of two weeks and another week for a vote? That kind of defeats the purpose. A gentlemen's agreement? Something else? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
On Sun, Mar 15, 2015 at 4:23 PM, Zeev Suraski z...@zend.com wrote: Sorry, but ... even though your original RFC was very unclear about this, everybody went by the all votes must start by the 15th interpretation that has been discussed in that thread. Do you think it's an accident that a whopping six RFC votes started today? It isn't. Please don't start reinterpreting things to fit your needs. I am personally totally fine with extending the PHP 7 timeline by say one month - but if we do that, let's make it official and applying to everyone, not just some particular RFC. I know for sure that there are a number of additional RFCs that would have been submitted for PHP 7 had anyone known that it'll be allowed. First off, this is Bob's interpretation which he brought up on Friday. Yes, ideally I would have read the original text during the discussion period and commented on it, but I didn't. I think the 3 month period for implementation (that's mostly done) and testing gives a very reasonable time period to absorb the most lax of interpretations. I think it would be a shame to delay the timeline for this, but I also think it would be a shame for the timeline - that was *clearly* not designed to create de-facto bias towards one RFC or the other - to do exactly that. Even if we were to push the timeline out by a bit, how do we do it? An RFC with a minimum discussion period of two weeks and another week for a vote? That kind of defeats the purpose. A gentlemen's agreement? Something else? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Even if we were to push the timeline out by a bit, how do we do it? This is ~My approach hasn't won yet, and instead of conceding default due to democracy in action, I would like to change the process. I am not insulting you. I am not attacking you. But this is some bizarre stuff that is more than sneaky, and you really need to stop. One RFC has won. Another RFC has lost. A third RFC is a backup plan and nothing more. Let the winning RFC win and lets get on with something else, because today is the feature freeze and you don't get to manipulate that to suit your own needs just because you want to. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Generator Delegation
On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey rdlow...@php.net wrote: This is actually a *vastly* inferior solution to language-level support for generator returns. greenlet/gevent does it this way because these libraries were created before Python supported generator delegation (and continue supporting Python 2.5). When you have generator returns you don't need any of that additional cruft. Instead, a language supporting generator returns can simply yield promises (or whatever concurrency primitive you prefer). Period. Hi Daniel, I actually disagree here. Using generators as coroutine is a hack, and is vastly inferior to having actual coroutine support in the language, but obviously we do what we can with the language we have. (Yes, I am in the camp that *really* dislike explicit yielding.) I do understand where this is coming from, so changing my vote to yes on the other RFC. Damien
Re: [PHP-DEV] A plea for unity on scalar types
On 03/15/2015 03:49 AM, Dennis Birkholz wrote: Hi together, Am 14.03.2015 um 14:37 schrieb Peter van Fessem: If a dev turns a file that he or she wrote into strict mode, then that only counts for that specific file. If you take over some code, then you can remove the declare line. *none* of those things you'd be able to do with ini settings. So don't shout out that nonsense FUD. It's equivalent to an ini setting in that it changes the behavior of the code based on something that is declared elsewhere. Obviously a declare statement in the top of the file is a lot better than an ini setting, but I think the principle is the same. that is simply not true. The principle is not the same. The principle is roughly the same as with namespaces. If you are unsure, got to the top of the file, finished. Ini-Settings are runtime-dependent so there is no way to find out what the ini-setting will be beforehand. I don't think we disagree on this. I was only trying to say that both ini settings and declare statements influence behavior of other code, and that in both cases you have to put some effort into looking up the current value, but that is where the comparison ends. I think nobody will argue that namespaces are to complicated because you can define the current namespace at the top of a file which than changes the behavior of the file completely (which it does, somehow, by the way). I'd never argue that namespaces are complicated, but they, like every language feature, add a non zero complication to the language, whether you would use them yourself or not. Looking at the top of the file isn't a massive problem, but it is a small one. If I didn't see the value in namespaces, I'd prefer not to have them in the language at all (but I do, so I don't). I'm arguing against statements like: Well if you don't like strict mode, don't use it.. It's not that simple. The fact that it exists adds a cost. Greets Dennis Thanks, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices
On Sun, Mar 15, 2015 at 6:32 PM, Markus Fischer mar...@fischer.name wrote: On 15.03.15 16:46, Nikita Popov wrote: To ensure we have no shortage of new RFC votes... https://wiki.php.net/rfc/reclassify_e_strict#vote Voting is open for ten days :) From the RFC: Signature mismatch during inheritance ... Possible alternative: Convert to E_DEPRECATED, if we intend to make this a fatal error in the future. Has there been any decision made which course to follow? I ask since I don't see voting option for it (not saying it needs one!), it just would be nice to carve in stone what's going to be done about it. Otherwise good cleanup RFC IMHO, +1 Thanks, I forgot to drop that before starting the vote. The note is gone now :) Nikita
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
On Sun, Mar 15, 2015 at 5:55 PM, Zeev Suraski z...@zend.com wrote: Bob, Thanks for the update. This time, though, although I completely respect your decision not to put your RFC into a vote unless the Dual STH mode fails, I'd like to either (with your permission) take over the RFC or propose my own copy and move it to voting as soon as allowed. This, under a commitment that if I see that Basic STH is failing to garner a clear majority, I'll retract it and move to support the Dual STH RFC instead for the sake of unity. Why am I making this admittedly big move? I think that waiting until we know for certain whether the Dual Mode STH would win is very problematic, for two reasons. The bigger one that it runs a serious risk we have no STH at all for 7.0. It's not an unlikely scenario either - it's probably 50/50% that the Dual STH RFC would fail, only to find later - when it's too late - that Strict campers have enough votes to block the Basic one. Personally, I find that the worst possible outcome, given how clearly it is that the users at large want *something*. If the Basic RFC is put to a vote but retracted if when we see it stands no chance to pass - combined with my commitment to support the Dual STH in such a case (and my belief that move will be able to influence others as well), the chances that we'd be left with no STH at all for 7.0 goes down significantly. There's also a secondary reason - I do think it's unfair that in a very likely scenario - we won't be giving people who prefer Basic STH only - at least at this point - a chance to vote at the proposal they think is best. I don't think it's a matter of voting for who's going to win; In fact with a commitment to retract it if it fails to win, it's not about that at all. It's being able to vote for what you truly believe in, as opposed to a compromise that you find bad but better than nothing. And in my case (and perhaps others) - it's about being willing to vote for something I actually don't believe it at all for the sake of unity, but only once the alternative options have been explored. Before Dual STH supporters dissect my move to pieces, please realize this: If you're right - that Basic STH stands no chance to gain 2/3 majority - you have absolutely NOTHING to lose, and in fact, you're increasing your chances of passing that vote through from apparently 50/50 to 80/20 (not talking about votes, but chances), and as a bonus, you get to prove your point. If you're wrong - and Basic STH is more popular than Dual STH (at this point in time) - we would have given the community at large something that's closer to what it really wants. Zeev -Original Message- From: Bob Weinand [mailto:bobw...@hotmail.com] Sent: Sunday, March 15, 2015 5:51 PM To: PHP Internals Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar Types Hey, to clarify what the way to go with this RFC is. This RFC is a FALLBACK. It's about the common part of both other RFCs. That way it *only* will go to vote after Anthonys RFC ends. And *only* if it fails. That means, I will go by the voting RFC and wait until discussion period ends and put it to vote after Anthony closes his RFC in case it fails. I'm aware that a few people have said, they will change their vote depending on what ever might pass. And that they asked for this RFC going into direct competition against Anthonys RFC. No. Know what you want. If you dislike Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't switch your votes back and forth depending on what might win. That's why I decided to not have the vote on this running concurrently with Anthonys. But, in any case this RFC will go to vote on the 24th if Anthonys RFC couldn't gather a 2/3 supermajority. Thanks, Bob -- 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 Hello, I like your idea, but there's a problem with this (apart from the thing that it's not supposed to be in vote for 7.0 if you go by the rules, based on opinion of some people here). You are saying we would have given the community at large something that's closer to what it really wants, but the people maintaining PHP vote on that, not the community and userland developers (and that's a problem with most of the features here, that the direction in which PHP evolves is basically chosen by C programmers*). *) Don't take it too literally or offensively please, but I hope you'll get what I mean. :) Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Basic Scalar Types
2015-03-15 19:13 GMT+01:00 Levi Morrison le...@php.net:
On Sun, Mar 15, 2015 at 12:03 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmax...@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be
consistent with our existing type hints for classes, callables and arrays,
NULL is not accepted by default, unless the parameter is explicitly given
a default value of NULL. This would work well with the draft Declaring
Nullable Types RFC.
This proposal has a different behavior here. It explicitly allows
nulls for types:
function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.
This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.
Anthony.
Anthony,
I think you've got something wrong there. It won't undermine an attempt at a
nullable RFC.
In the weak scalar typing world, nullables won't change what we accept, but
what we receive.
function (int|null $abc) { var_dump($abc); }
(or ?int or whatever syntax we will use)
would allow null to *not* be casted here.
Means foo(null) will lead to $abc being null and not int(0) with that
signature.
I think allowing `null` for an `int` is an error. Converting a null to
zero on a type boundary is harmful in my opinion.
I agree, `null` shouldn't be allowed for `int`.
--
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
