Re: [PHP-DEV] [VOTE] Reserve even more type hints
On Mon, Mar 16, 2015 at 7:37 PM, Dan Ackroyd dan...@basereality.com wrote: On 16 March 2015 at 06:44, Sara Golemon poll...@php.net wrote: The voting period for the Even More type hints reservation RFC is now open. There's been a little bit of traffic on the list in the past few days; I don't think your RFC has received enough cogent discussion. I can't force people to talk about something. Especially something so minor while the war-of-the-century is being waged. In particular the keywords 'Resource' and 'mixed' seem to have limited need to be reserved. I don't believe there has been any suggestion that either of these would actually be used as types for PHP 7.x. So making them be unusable seems to be a large BC hit for no gain for people who currently have classes that use them To be clear, this RFC is about declaring these names as reserved, not about actually /using/ them. There's no language in the RFC about actually throwing errors or other code-breaking behavior. Therefore, even should all of them pass, it does *NOT* mean that your code using these names suddenly stops working on PHP7. It means that you have been warned that using the names of intrinsics is a bad idea, and that the language reserves the /right/ to make doing so an error at some point in the future. Can anyone please make a strong argument for why 'resource' and 'mixed' should be reserved, if we currently have no plans to use them? In the case of resource, because it refers to a real type in PHP's type system. Using that intrinsic as an arbitrary label is a bad idea. It'd be like putting your project's code in the PHP namespace. There's nothing in the language preventing you from doing so, but it's a bad idea. Formalizing that it's a bad idea is what this RFC does. As far as mixed... I don't have a strong reason for it. TBQH, I'm not strongly in favor of all of these supplemental types. but they're included for completeness, and presented as individual voting options for flexibility. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi Anthony, On Tue, Mar 17, 2015 at 6:03 AM, Anthony Ferrara ircmax...@gmail.com wrote: Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Congratulations. Even though I dislike stirct_types part, I appreciate your efforts. Since weakly typed mode is too weak to be useful for detecting possible errors and strict type mode is overridden by any caller(parent script), it's still reasonable to have CoerciveSTH RFC. I hope many of us see the benefits of the RFC also. BTW, I suggest to remove the word strict from strict_types at least as it is not strict at all if caller(parent script) does not specify strict_types=1. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi! Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Despite my previous disagreement with this RFC, I'd like to thank Anthony for all his work on it and persistence and congratulate us all for finally arriving at the decision. I'd like also to thank everybody who contributed to the discussion and participated in the probably most representative vote ever held. Let's get on the road for PHP 7 GA and make it the best PHP release ever. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Thank you Andrea and Anthony. Your efforts are much appreciated! - Jon On Mon, Mar 16, 2015 at 4:03 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Connect with me on *http://twitter.com/jwage* http://twitter.com/jwage
Re: [PHP-DEV] [RFC] Introduce Type Affinity
Hi Pierre, On Tue, Mar 17, 2015 at 7:23 AM, Pierre Joye pierre@gmail.com wrote: I very much appreciate your consistent effort to improve php, at all levels. However I won't comment on this RFC or any further RFCs trying to target 7. My reasoning is that we should now focus on getting it out, in time. I did not agree with the time plan about 7 development but it is what we decided. Let get back to work now. I agree that we should concentrate for PHP7.0. The reason why I raised this topic is currently proposed strict_types does not work well with this. If inputs are converted/validated as certain types with or without this RFC, strict_types should raise error for mismatched types. However, current proposal does not do this depending on how strict_types is used... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Introduce Type Affinity
On Mar 17, 2015 9:42 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Pierre, On Tue, Mar 17, 2015 at 7:23 AM, Pierre Joye pierre@gmail.com wrote: I very much appreciate your consistent effort to improve php, at all levels. However I won't comment on this RFC or any further RFCs trying to target 7. My reasoning is that we should now focus on getting it out, in time. I did not agree with the time plan about 7 development but it is what we decided. Let get back to work now. I agree that we should concentrate for PHP7.0. The reason why I raised this topic is currently proposed strict_types does not work well with this. If inputs are converted/validated as certain types with or without this RFC, strict_types should raise error for mismatched types. However, current proposal does not do this depending on how strict_types is used... I do not see your point with strict type and what your RFC proposes is what ext/filter does. I would really not to start again this kind of discussion while trying to get 7 out in time as it is already quite a challenge.
Re: [PHP-DEV] [VOTE] Reserve even more type hints
On 16 March 2015 at 06:44, Sara Golemon poll...@php.net wrote: The voting period for the Even More type hints reservation RFC is now open. Hi Sara, There's been a little bit of traffic on the list in the past few days; I don't think your RFC has received enough cogent discussion. In particular the keywords 'Resource' and 'mixed' seem to have limited need to be reserved. I don't believe there has been any suggestion that either of these would actually be used as types for PHP 7.x. So making them be unusable seems to be a large BC hit for no gain for people who currently have classes that use them It's possible that people are voting yes to reserve these two words, without fully considering whether they should be reserved or not. I can see that all of 'object', 'scalar', and 'numeric' have been proposed as part of future improvements to PHP's type system. Can anyone please make a strong argument for why 'resource' and 'mixed' should be reserved, if we currently have no plans to use them? cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
Hi Mike,
On Tue, Mar 17, 2015 at 5:03 AM, Mike Willbanks pen...@gmail.com wrote:
Let see how it looks if strict_types is renamed to raise_type_error
?php
declare(raise_type_error = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(raise_type_error = 1);
require lib.php;
foo(123); // will give an error
?
Is everyone feel OK with this??
That seems far more odd in my opinion. I vastly prefer the first.
The name implies what it does.
The reason you think this is odd is because the behavior is odd.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] 回复： [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function
Hi Peter: Sorry to reply late, because the GFW, I can’t access *.google.com at home. On 16 March 2015 at 14:59, Xinchen Hui larue...@php.net (mailto:larue...@php.net) wrote: Hey: On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn petercowb...@gmail.com (mailto:petercowb...@gmail.com) wrote: On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com (mailto:zxcvda...@gmail.com) wrote: Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Could you add a paragraph or two explaining the reasons for choosing this particular proposal? Some examples of what I would like to read: - why we can't do preg_replace_callback($array_of_regexes, $array_of_callbacks, $subject) array() also could be a valid callback.. (array(clasname, methodname)). - why not preg_replace_callback($array_of_regex_to_callback_pairs, $subject) there are also $limit, $count argument could be used. - why not pass the regex used to the callback, as per Laruence's earlier RFC bc break..(change the callback's signature) And give a few links to historical discussions in the same sort of area? E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq). thanks I accept, and I will be add these details in RFC. In case my earlier message wasn't clear, I was asking for the RFC itself to be padded out with those sorts of details. The reason being, many (most) people won't be already familiar with the surrounding discussions that have happened previously, or the reasons for the potentially strange-seeming design choices made in this RFC. Thanks for the suggestion. :) Any objections? — Best, Wei Dai -- Xinchen Hui @Laruence http://www.laruence.com/ — Wei Dai -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Tue, Mar 17, 2015 at 9:45 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Anthony, On Tue, Mar 17, 2015 at 6:03 AM, Anthony Ferrara ircmax...@gmail.com wrote: Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Congratulations. Even though I dislike stirct_types part, I appreciate your efforts. Same here. anyway, I think there is no time doing any changes on this. Let's wait and see, how the community use this strict_types.. anyway, I am glad this thread is finally done. thanks Since weakly typed mode is too weak to be useful for detecting possible errors and strict type mode is overridden by any caller(parent script), it's still reasonable to have CoerciveSTH RFC. I hope many of us see the benefits of the RFC also. BTW, I suggest to remove the word strict from strict_types at least as it is not strict at all if caller(parent script) does not specify strict_types=1. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 8:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
I think this is important, but not many people realize the importance.
Therefore I created this as a new thread at the last minutes of vote.
On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
lib.php
?php
declare(strict_types = 1);
function add(int $a, int $b) {
}
?php
add($_GET['a'], $_GET['b']);
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
that is not right and has been discussed a thousand times over.
The declare changes the rules only for function calls in the file it is
declared in.
so:
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
If this kind of behavior is allowed, why strict mode is called strict?
It's not
strict at all if mode could be overridden.
strict_mode is just controlling errors, then it should be named as error
controlling directive and raise E_WARNING/E_TYPE or whatever.
Even if what its controlling is error that can be overridden by caller, yet
calling it strict_types is not correct. Proper name would be something
like raise_type_error.
Let's see how it looks if strict_types is renamed to raise_type_error
?php
declare(raise_type_error = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(raise_type_error = 1);
require lib.php;
foo(123); // will give an error
?
Is everyone feel OK with this??
There are other things I would like to mention, but this would be enough
to change decision hopefully.
Regards,
P.S. If we are going to introduce strict types for basic types, what we
really need is type affinity for inputs. e.g. $_GET/$_POST/$_COOKIE.
https://www.sqlite.org/datatype3.html
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hello,
this would make more sense than strict types, which is a bad name
anyways (as I already mentioned in some other email) - because the
concept of non-week typing is usually called strongly typed in any
other language I can think of. Does PHP have to be a special
snowflake?
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I think this is important, but not many people realize the importance. Therefore I created this as a new thread at the last minutes of vote. ... strict_mode is just controlling errors, then it should be named as error controlling directive and raise E_WARNING/E_TYPE or whatever. Even if what its controlling is error that can be overridden by caller, yet calling it strict_types is not correct. Proper name would be something like raise_type_error. Let's see how it looks if strict_types is renamed to raise_type_error ... ?php declare(raise_type_error = 1); require lib.php; foo(123); // will give an error ? I agree that the name doesn't by itself explain the feature, but how could it possibly? You'd end up with something like: declare(raise_type_errors_on_parameter_mismatches_when_calling_functions_from_this_file_regardless_of_where_the_functions_are_defined_and_what_the_setting_is_in_other_files=1); I don't think your suggestion explains the feature any better than strict_types. (Although the irony of using =1 instead of =true isn't lost on me!) -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
Le 16/03/2015 12:39, Xinchen Hui a écrit : Hey: And last comment, if there no such declare thing, I will definitely vote yes to this RFC. Hi Xinchen, You can also not vote at all, that's a very valid option. By voting yes, you say that you want PHP developers to have access to STH in PHP 7, by voting No, you say that you don't want PHP developers to be able to use STH in PHP 7. By not voting, you let the rest of the PHP community that cares about STH (both for and against) decide if the feature gets in the language. As a person with voting rights, you should study the RFCs in details, understand them fully and vote on what you think you have understanding and expertise on. There is no obligation to vote on all RFCs. It seems that you won't use STH yourself so you will probably never use declare in your code and won't be impacted by the existence or not of the feature. I also don't like how the declare syntax looks, and similarily I personnally dislike even more how ugly the namespace syntax is in PHP with the backslashes (Foo\Bar\Baz), yet, I am happy that we do have the possibility to namespace our code, because PHP 5 *needed* that feature. And I think PHP 7 needs something like that, I also think it's a very clever solution as we can keep on using PHP as a weakly typed language as usual but also strenghten some of our code that needs strong typing. that's why I want vote no for this, and wait for Bob's Basic STH. thanks It's too late, Bob's Basic STH missed the schedule for PHP 7, it was proposed way too late and the coercive STH RFC has just zero chance to pass, it's too much of a BC break for everybody. The dual mode STH is the only chance to have something for PHP 7 and remain competitive with HHVM, Node.js… that we see people switch to. Baidu switched to HHVM, Wikipedia too, in my country big names switched from PHP to node.js and that was not just for performance reasons, it was also for the features. Zeev himself admitted that we need something for PHP 7. Personnally, I think the dual mode is a very clever way to please all PHP developpers, those that want to use weak typing, those that want to use stronger typing and those like me that would continue to use weak typing because it's convenient but would be happy to use STH on very specific parts of his code that would benefit from it. Cheers, Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
Hey: On Mon, Mar 16, 2015 at 9:32 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Le 16/03/2015 12:39, Xinchen Hui a écrit : Hey: And last comment, if there no such declare thing, I will definitely vote yes to this RFC. Hi Xinchen, You can also not vote at all, that's a very valid option. By voting yes, you say that you want PHP developers to have access to STH in PHP 7, by voting No, you say that you don't want PHP developers to be able to use STH in PHP 7. By not voting, you let the rest of the PHP community that cares about STH (both for and against) decide if the feature gets in the language. As a person with voting rights, you should study the RFCs in details, understand them fully and vote on what you think you have understanding and expertise on. There is no obligation to vote on all RFCs. It seems that you won't use STH yourself so you will probably never use declare in your code and won't be impacted by the existence or not of the feature. I also don't like how the declare syntax looks, and similarily I personnally dislike even more how ugly the namespace syntax is in PHP with the backslashes (Foo\Bar\Baz), yet, I am happy that we do have the possibility to namespace our code, because PHP 5 *needed* that feature. And I think PHP 7 needs something like that, I also think it's a very clever solution as we can keep on using PHP as a weakly typed language as usual but also strenghten some of our code that needs strong typing. that's why I want vote no for this, and wait for Bob's Basic STH. thanks It's too late, Bob's Basic STH missed the schedule for PHP 7, it was proposed way too late and the coercive STH RFC has just zero chance to pass, it's too much of a BC break for everybody. The dual mode STH is the only chance to have something for PHP 7 and remain competitive with HHVM, Node.js… that we see people switch to. Baidu switched to HHVM, Wikipedia too, in my country big names switched from PHP to node.js and that was not just for performance reasons, it was also for the features. Zeev himself admitted that we need something for PHP 7. Personnally, I think the dual mode is a very clever way to please all PHP developpers, those that want to use weak typing, those that want to use stronger typing and those like me that would continue to use weak typing because it's convenient but would be happy to use STH on very specific parts of his code that would benefit from it. don't worry, it will pass thanks Cheers, Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dual Mode STH
Hey: On Mon, Mar 16, 2015 at 10:21 PM, Zeev Suraski z...@zend.com wrote: All, After much thinking, and despite grave concerns I raised about what transpired in the last 24 hours, I decided to get behind the Dual Mode RFC at this time. I call upon everyone - both people that haven’t yet voted and those who voted no - to do the same so that we ensure that we have STH in PHP 7.0: wiki.php.net/rfc/scalar_type_hints_v5#vote As I’ve said all along, I’m not doing it because I think it’s good, I actually think it’s pretty bad – both in absolute terms and in the precedent for introducing ‘both’ options instead of a single opinionated one. That move is designed to help ensure that we have SOME form of Scalar Type Hints in PHP 7.0, which is clearly what the userbase at large wants. We can revisit casting rules in the future without time pressure, and in general, see how this new feature is accepted and used. Again, I call upon everybody to vote Yes for the Dual Mode RFC to ensure that we have some form of STH in PHP 7.0. Unecessary for everybody, one or two change from no to yes will make it pass. :) thanks Zeev -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: dustin
Maintaining the documentation -- 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 Matteo, On 16.03.15 12:43, Matteo Beccati wrote: On 15/03/2015 19:30, Matteo Beccati wrote: 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. So... I've spent a few hours on the cleanup and I'm still far from getting a green build. As you mentioned in the RFC, turning E_STRICT into E_WARNING is going to be a BC-break for someone, and fixing this one in particular requires far more effort than a simple search/replace. am I correct assuming that your existing test suite was running with E_STRICT excluded from error_reporting ? thank you, - Markus -- 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 16/03/2015 13:28, Markus Fischer wrote: am I correct assuming that your existing test suite was running with E_STRICT excluded from error_reporting ? Of course. 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] STH and the 3 RFCs
On 16/03/15 11:54, David Muir wrote: On 14 Mar 2015, at 6:41 am, Lester Caine les...@lsces.co.uk wrote: On 13/03/15 18:53, guilhermebla...@gmail.com wrote: By considering PHP's nature, having a dual mode is a WTF. I can see myself asking multiple times a day is this file strict or not? to trace potential bugs or type juggling. I do want strict, but I don't think it's the right time for PHP to make this move. Userland would have strictness, but all internal functions are a weird WTF type juggling mode. I originally switched my vote many times in the v3 of the RFC, mainly because PHP developers are the ones that would suffer by these configurability on a daily basis. I ended up with a YES vote because when considering STH or nothing at all, I prefer to have some. The bigger WTF is perhaps that moving forward one has no idea just what a third party library is using internally. A case has been made that this does not matter since calling that library from a non-strict site will simply work as now, but in that case the library is not designed to handle non-strict input. It assumes that the strict check happens, where a well designed 'weak' library will be handling the edge cases properly. It not simply a matter of is this file strict or not? but rather what happens when I pass the wrong data?. If I've understood the RFC's correctly, your point is moot. With any scalar type hints, a library will not be able to tell how it is being called. All it knows is that it has received an int, string, float, or boolean where it has asked for one. A library written in weak or strict mode will have no bearing on its public API. This is the case with all of the STH RFCs. So no, a weak mode library is not better off. It is actually worse off because it has more edge cases where things could go wrong (internally), while a strict library will not function at all until the edge cases are actually taken care of. As far as being a user of the library itself, the strictness or weakness of the library code is irrelevant. You can use a weak library in strict mode, and the library would never know or care. if you decide to make all your own code strict, you're not changing the behavior of the library. If you make all your own code weak, you're not changing the behavior of the library. Even if you strips out all the declare strict statements, it will not change the behavior of the library (except in the case where the code was broken and wasn't even working previously!). I think the best way to explain the dual mode RFC is to think of it like this: Imagine PHP threw a COERCIBLE_TYPE_MISMATCH notice whenever you pass the wrong type to a function. In weak mode, the type gets coerced, the notice is ignored, and we truck along as if nothing happened. Strict mode is basically where you've set up a custom, per-file error handler where COERCIBLE_TYPE_MISMATCH notices are turned into fatal errors. It is your code that decides which error handler to use. Thank you for that David ... It makes sense of a number of points. I think that what I really need is a simple crib sheet of 'just' weak typing in this RFC and if that conflicts with my own current program flow. I simply don't subscribe to the implication that type hinting is essential to make PHP better. I just prefer in-line error handling to exception handlers. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On 16 Mar 2015, at 11:16 pm, Pavel Kouřil pajou...@gmail.com wrote: On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd dan...@basereality.com wrote: On 16 March 2015 at 11:49, Pavel Kouřil pajou...@gmail.com wrote: Seriously, think about it for a while - when some setting that changes how code behaves was a good idea? The problem is that there are two irreconcilable camps - some people want weak STHs, other people want strict STHs. This RFC gives both camps what they want, at the cost of having the dual mode. I personally would prefer a single mode, with strict STHs but I can see that would piss off the other camp. And so to me, this RFC even with the ickiness of the setting, is an an acceptable cost to giving both sides what they want. Oh, and people who don't want to use scalar type hints at all, can still continue to not use scalar type hints, and their code will continue to keep working. Anyone who is voting no, isn't doing so because they are missing out on a feature, they're doing it to block other people from getting what they want in PHP, which is just a terrible way to vote. And if the strict camp are wrong and strict scalars are just not used by a large proportion of the PHP community, it would be trivial to remove support for the strict mode in a future version of PHP, as all code that runs in strict mode, will automatically work in weak mode. cheers Dan I can't speak for anyone who voted, but personally, if I could vote, I would voted no - not because I don't want to block people from getting what they want, but because I sincerely think that having ANY setting that changes code's behavior is bad in the long run (and that Do you use an error handler that converts notices into exceptions? By your statement, I'm guessing no, and that you think error handlers should not be used that way as they change the code's behavior in almost exactly the same manner? removing the feature might not be really easy, once people realize that the feature is really bad, as people realized with safe_mode and register_globals after few years). Removing the feature is trivial! A search / replace across the code base can do it, and it could be disabled at the engine level. For working code, nobody would notice the difference because strict code works in weak mode. In other words, there are no BC issues with removing the strict portion. Can people stop comparing it to register globals? Have you ever tried to fix a codebase that relied on it? It is impossible to detect! You really don't have many options but to step through and manually run through every single entry point into your application and test/audit every code path, and the hope you catch everything. It was a global setting, removing it was a *huge* BC break, and its use was undetectable. None of which is the case with dual mode. There's no global setting, there's no BC with removing it, and it's use is *extremely* easy to detect! Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
On 3/15/15 11:05 PM, Yasuo Ohgaki wrote:
Hi all,
On Mon, Mar 16, 2015 at 11:50 AM, Eli e...@eliw.com wrote:
Currently, I can speak for myself, I almost always find myself doing a
'backup' step in coding. Because in this situation my process becomes:
if ($zebra ... Oh wait, can't do that, need to use in_array
if (in_array( ... Oh wait, what's the order of parameters again? dang it,
hit php.net or find a recent use.
if (in_array($zebra,$zoo)) {} ... *shew*
In the end, yes, you can argue that this is a small thing. But I believe
that the simpler cognitive path that one follows with this new syntax will
bring some great benefit to coders.
This is one of the issue what I'm trying to fix by this RFC.
https://wiki.php.net/rfc/consistent_function_names
This would be better fix for this issue.
Note: I added parameter issue handling to the RFC.
However your proposal here (it's own merits aside), doesn't actually
address what I mentioned. Since it still requires the use of a
'function first' phraseology instead of a more natural language one.
If anything, it actually might hurt this one specific case. Because at
least now, the function has a logical process to it, if you think about
it. IE: in_array(what, array). Whereas switched as your proposal
allows for: array_in(what, array). Means the function name is kinda
backwards comparatively.
Also, it reads as if it's something else. I'd expect by natural
language, that array_in ... would look for an array in something. Not
the other way around.
Eli
--
| Eli White | http://eliw.com/ | Twitter: EliW |
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
On 3/16/15 2:21 AM, Stanislav Malyshev wrote:
if ($zebra in $zoo) {}
Two things here:
1. If you're looking whether your zoo has a zebra, and you're doing it
by inspecting every inch of your zoo and checking if it doesn't contain
a zebra by any chance, you're running your zoo wrong. I hope this
metaphor is clear :)
Heh heh. True. However the flip side is that this ends up being a
rather common practice (for good or bad). Stuff like Is this state in
my array of all states or Is this country in my array of all
countries ends up happening a lot.
I like (personally) having this simplified syntactic sugar on this.
2. We don't talk to computers in natural language. For many reasons. So
part of the cognitive process of any programmer is translating his
thoughts into patterns that particular software (we rarely talk to
hardware directly anymore) understands. From that POV, it doesn't matter
too much how exactly bytes that you use to represent it are arranged, as
long as they are not unnecessarily unwieldy. That, of course, is a
matter of opinion, and my opinion is in_array is fine in that regard.
Totally understood. Though my argument wasn't about bytes. But just
'simplified brain to code'. Since one could start arguing that we start
coding in whitespace instead :) (ok ok, that was a joke).
But yeah. I get your POV on that. My own brain just looks at the in
syntax and goes: oooh, that's what I wish it had been from the beginning
And the newer people to the language often get tripped up on exactly
these kinds of things. Lowering that cognitive barrier to translating
one's thought, to code. I feel is going to be a benefit here.
Frankly, I don't see how that would help. Because with this operator,
you'd have to tell them:
1. It's the same as in_array function, it goes through array and checks
if the element is there.
2. But not exactly - in_array can do non-strict lookup, this one can't.
3. Oh, but instead it also works on strings.
4. Where it is like strstr except it doesn't tell you *where* the
substring is.
5. And if you want to use it like Python's in you shouldn't because
Python's works on keys while ours works on values.
6. And unlike many other languages you can't use it in a loop either.
7. And if you want to write an *efficient* lookup you shouldn't use this
operator at all.
I don't think it is a cognitive simplification.
Yeah - those are good points. Though I'd see this from the POV of
step-by-step knowledge transfer. You wouldn't teach look at all these
complications.
You'd be able to give the '1st day lesson' on How to see if something
is in an array ... and How to see if a string is in another string.
And showing them this simpler cognitive version. But then you start
going deeper on 'advanced stuff' later :) (and yes, in_array becomes
'advanced stuff' at that point.
It's too bad that there isn't a way to do an operator like this, in such
a way that it's more efficient and/or allows for non-strict like in_array.
Thanks for the input Stas ... I'll keep mulling this over and seeing
what others say here as well.
Eli
--
| Eli White | http://eliw.com/ | Twitter: EliW |
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Voting irregularities
On 15.03.2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote: kk - no That is me. And I voted no on a broken poposal. K -- Kristian Köhntopp http://google.com/+KristianKohntopp signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Voting irregularities
On 15 March 2015 at 15: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. Extra! Extra! Read all about it: voters come out of the woodwork to vote on contentious issues! (Sorry, just poking fun...) 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? The user page [1] on master.php.net shows when they applied for an account (and sometimes other notes), which is generally roughly the same time as getting an account within days/weeks. [1] E.g. https://master.php.net/manage/users.php?username=salathe (accessible only to folks with @php.net accounts) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
On Sun, Mar 15, 2015 at 10:07 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Netroby,
On Mon, Mar 16, 2015 at 12:03 PM, Netroby hufeng1...@gmail.com wrote:
Does the in support this kind of php code ?
```php
?php
$arr = ['a', 'b', 'c'];
for ($v in $arr) {
echo $v;
}
```
I know javascript has this kind of support
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
No. We have foreach for this.
Shells support this syntax, too.
It may be confusing for some users. Good point.
I had made this point earlier; not having it was not in particular a hurdle
for me but I did believe that if we added the in clause we could also
follow that type of for loop.
Re: [PHP-DEV] Voting irregularities
On 16.03.2015, at 15:03, Kristian Köhntopp k...@koehntopp.de wrote: That is me. And I voted no on a broken poposal. And because some people asked, the kk account is not new. I have been using PHP since about 1997/98, joining the community around the times of the first PHP 3.0 beta-releases. Boris Erdmann and I wrote something called PHPLIB (http://marc.info/?l=php-generalamp;m=90222503034131amp;w=2, http://marc.info/?l=php-generalamp;m=90281652210710amp;w=2) which implemented some kind of session management that has been rewritten into the session module of PHP 4. I also wrote the Posix and Recode extensions back then, worked on the LDAP extension, and dissed Zeev because of the C++ way of implementing constructors instead of using __init or __construct (http://www.mail-archive.com/php-dev@lists.php.net/msg36275.html, and many other messages before that). I also annoyed people into implementing __get, __set and __call, which over time became http://php.net/manual/en/language.oop5.magic.php I blogged https://plus.google.com/u/0/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB, and apparently that motivated a number of people to look into this and form an opinion, which is good. PHP already has too many things that can be enabled and disabled at the language level, and too many ways to enable and disable functionality in the language. It should have one typing system, not many and certainly not any way to switch these on and off, no matter how. At the current state and climate of discussion I personally think it would be best for the language and the community for each and every proposal to change the type system to fail or be withdrawn. From my current experience, it may have been best for the language to have chosen the Python way of things back 20 years ago 3 + 2 Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for +: 'int' and 'str' 3 + int(2) 5 3 + int(2a) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for int() with base 10: '2a' but it is too late now. Neither of the current proposals actually improves a lot for anybody, but making that improvement optional, how little it may ever be, is just insane. If you MUST have one proposal succeeding, I am of the opinion that one should support the one by Zeev with the modification that it actually warns about things instead of erroring right now (E_DEPRECATED or something), and make that errors in the release after the current. I do think that because it is ONE type system, not optional and because it actually finds things that are broken and complains about these. Just make the transition more gradual than it is now, in order to ease adoption. K -- Kristian Köhntopp http://google.com/+KristianKohntopp signature.asc Description: Message signed with OpenPGP using GPGMail
RE: [PHP-DEV] STH and the 3 RFCs
Hey David, A library written in weak or strict mode will have no bearing on its public API. Strictly speaking (pun intended), this is not true. A library can easily expose a facade that enforces a user of that library (who is in weak mode) to have to write in strict mode [1]. Once more, this can be done unintentionally [2] because of the caller-deciding semantics. These examples can be further extended into wrapper classes, nested library dependencies, etc. Sure, you could argue that this could easily be turned off by simply removing the top declare() statement of that library, but modifying the library in itself introduces complications - especially when using dependency managers like Composer. [1] https://gist.github.com/tpunt/4830d18d47e2df021c2f [2] https://gist.github.com/tpunt/eecfed2495bdccb73632 -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function
On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote: Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Could you add a paragraph or two explaining the reasons for choosing this particular proposal? Some examples of what I would like to read: - why we can't do preg_replace_callback($array_of_regexes, $array_of_callbacks, $subject) - why not preg_replace_callback($array_of_regex_to_callback_pairs, $subject) - why not pass the regex used to the callback, as per Laruence's earlier RFC And give a few links to historical discussions in the same sort of area? E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq). Any objections? — Best, Wei Dai
Re: [PHP-DEV] About declare(strict_types = 1)
Hi Pierre,
On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye pierre@gmail.com wrote:
On Mar 16, 2015 6:46 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dennis,
On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
Caller _must_ satisfy callee requirements. This is simple principle
to
write a secure code.
With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is ignored and it leads security
breach.
that is simply not true! The callee always gets the type it expects.
There is no security problem involved here. The only difference is if
type conversion rules apply or if an error is raised for a type
mismatch.
You clearly dislike the RFC (you voted no), that is OK, but don't
scream
of security bugs that don't exist. If they would exist, all type hint
RFCs would have them in general.
Not only Java/etc programmers but also PHP programmers will assume type
safety by types.
Programmers assume integer type data is safe once it passes as integer
type
parameter.
I'm sure PHP programmer do assume the same thing.
I posted bad code
?php
function check_num_range(int $num) { if ($num 0 || $num 100)
trigger_error('Invalid range'); }
// Somewhere far from function definition.
$num = $GET['num'];
// Somewhere far from $num definition.
check_num_range($num); // Trying to check validity, int and range.
echo 'You have '.$num. ' now br /'; // But $num could have any string.
//
check_num_range((int)$num) wouldn't help also.
?
Caller controlled strict typing makes this worse... i.e.
?php
declare(strict_types=1);
// We are safe since $num is strictly int. Callee has responsibility to
pass valid int . (But it's not)
function check_num_range(int $num) { if ($num 0 || $num 100)
trigger_error('Invalid range'); }
?
Setting register_globals=On while callee script assumes
register_globals=Off is bad thing to do.
Similar argument applies to declare(strict_types=1) also.
As I suggested in other thread, we are better to sit down and make
reasonable decision.
It's not religion, but technical issue. We can reach reasonable consensus
if we try to. If we
cannot, it is better to introduce weak type hint only for the time being.
So basically you mixed topics and voted no for the one RFC that would
allow what you want to do later while allowing strict hinting already.
Accepting the other means changing casting rules again later at best. Not
sure you did well here ;-)
I thought majority of us see the benefit of StrictSTH over this RFC. You're
right about it.
This RFC will have serious consequence.
We made mistake with safe_mode. The main reason it failed is it did not
force
caller to have responsibility to make it work as it should. This RFC does
the same
for how declare(strict_types=1) works.
Aren't we learned from safe_mode lessons?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] About declare(strict_types = 1)
Hey:
On Mon, Mar 16, 2015 at 7:33 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:
On Mon, 16 Mar 2015, Xinchen Hui wrote:
On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com
wrote:
On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
is that right?
You got the answer but one thing bothers me a lot right now.
How did you vote against this rfc while missing the core point of it
(after
actually having a strict mode)?
as I said,
acutaly, I believe in most applications, they will still keep this
off..
so why we introduce such thing?
I don't like strict_types at all..
To be frank, I don't think I don't like this is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the declare *syntax*, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
*best* bet, I can only vote yes.
Are you sure on your bet?
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
a.php:
?php
require lib.php;
foo(123); // will work
?
b.php:
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
And last comment, if there no such declare thing, I will definitely
vote yes to this RFC.
that's why I want vote no for this, and wait for Bob's Basic STH.
thanks
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
This RFC will have serious consequence. We made mistake with safe_mode. The main reason it failed is it did not force caller to have responsibility to make it work as it should. This RFC does the same for how declare(strict_types=1) works. Aren't we learned from safe_mode lessons? I am not sure why you mention safe_mode as this has absolutely nothing to do with scalar type hints. Not feature wise, not implementation wise. safe_mode, first of all, was a global INI setting. The developer couldn't turn it off easily. That was probably at least 80% of the pain. The second part was the name, as it indicated that it made your scripts safe: It didn't. STHv5 does not suffer from either issue — developers can pick and choose the best solution for *them* (give them some credit, most developers are actually smart!). Library authors always get the right type if they type hint, which is *their* main pain point. And the type names have always already been used for casts anyway, and don't include safe in their name. cheers, Hello, it's similiar to the safe_mode though. Sure, it's not as bad as INI setting, but the intent is the same - a switch changing how code behaves. When I talked about the Dual Mode with some friends who are userland PHP devs (either current or former, because they switched to other stuff), none of them called the Dual Mode a great idea. The responses I got were mostly along the lines of wow, this seems really weird to WTF are those developers smoking. Everyone of them (sure, ~10 people isn't really representative number) said that they think PHP needs STH, but not this Dual Mode stuff. Seriously, think about it for a while - when some setting that changes how code behaves was a good idea? (IMHO never.) Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, 16 Mar 2015, Jordi Boggiano wrote:
On 16/03/2015 11:49, Pavel Kouřil wrote:
it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the intent is the same - a switch changing how code
behaves.
ini_set('memory_limit', 10); also changes how your code behave
And so does namespace Foo; use Foo/DateTime as DateTime; - on exactly
the same level as declare...
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Basic Scalar Types
On Fri, Mar 13, 2015 at 9:33 PM, Stelian Mocanita steli...@php.net wrote: So to get it clear for everyone: the right way is for internals to ignore community as a whole, stick to their own views and implement something nobody actually wants Few people already told - they like this. Thanks. Dmitry. - just because there is no time - on the idea that something is better than nothing? Without pointing any fingers it sure looks like a stalling tactic where someone eventually gets what they want. Highly disappointed on this outcome. On Fri, Mar 13, 2015 at 6:20 PM, Eli e...@eliw.com wrote: Not that another +1 is needed, but I'm with Andi here. I do personally like this 3rd proposal as an option, if nothing else because it implements the 'simpler base' at the moment, and allows us, once people are used to this being part of the language, to continue to evolve later. And that evolution can be based upon our real world experience of using this 'base level' of typehinting for a while. Versus the more complicated versions, of which both Zeev's and Anthony's are. In each their own way. Eli On 3/13/15 1:17 AM, Andi Gutmans wrote: Agree and I would vote +1 on this even if I'd prefer coercive. It is a very valid option for a 7.0 and it is future proof. -- | Eli White | http://eliw.com/ | Twitter: EliW |
Re: [PHP-DEV] About declare(strict_types = 1)
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:
On Mon, 16 Mar 2015, Xinchen Hui wrote:
On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com
wrote:
On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
is that right?
You got the answer but one thing bothers me a lot right now.
How did you vote against this rfc while missing the core point of it
(after
actually having a strict mode)?
as I said,
acutaly, I believe in most applications, they will still keep this off..
so why we introduce such thing?
I don't like strict_types at all..
To be frank, I don't think I don't like this is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the declare *syntax*, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
*best* bet, I can only vote yes.
Are you sure on your bet?
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
a.php:
?php
require lib.php;
foo(123); // will work
?
b.php:
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] About declare(strict_types = 1)
Hey: On Mon, Mar 16, 2015 at 7:18 PM, Derick Rethans der...@php.net wrote: On Mon, 16 Mar 2015, Xinchen Hui wrote: On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com wrote: On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote: that means, I need to add a lots of (int) while I try to call a function in a library which is not written by myself. is that right? You got the answer but one thing bothers me a lot right now. How did you vote against this rfc while missing the core point of it (after actually having a strict mode)? as I said, acutaly, I believe in most applications, they will still keep this off.. so why we introduce such thing? I don't like strict_types at all.. To be frank, I don't think I don't like this is a terribly good reason to vote against (or for something). What is important is how many people would actually benefit from a feature, without it causing issues for others. I am certainly no fan of the declare *syntax*, but I do know, from talking at conferences that many many developers would like to see scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and I think they just want a weak type hintings(PHP is a weak type language).. not strict types. especially not a dual mode, switch on/off by a declare line.. it looks so ugly to me.. strict (mode 2). It even caters for people that don't want to use them at all, as they can simply not use them. I also know, that without a dual mode, it seems very unlikely for scalar type hints to make it into PHP 7, and I don't think that is what users want. As this is our *best* bet, I can only vote yes. I understand your choice, but for me, as a six year PHP user. I can see how strict types can benifit me.. the only usage I can image is, turn on it in developer env to clean types passing, and turn off in produce env for safety(in case I forget to cast some types from $_GET $_POST). which is definitlely can be done by a extension, or hook.. thanks cheers, Derick -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] STH and the 3 RFCs
On 14 Mar 2015, at 6:41 am, Lester Caine les...@lsces.co.uk wrote: On 13/03/15 18:53, guilhermebla...@gmail.com wrote: By considering PHP's nature, having a dual mode is a WTF. I can see myself asking multiple times a day is this file strict or not? to trace potential bugs or type juggling. I do want strict, but I don't think it's the right time for PHP to make this move. Userland would have strictness, but all internal functions are a weird WTF type juggling mode. I originally switched my vote many times in the v3 of the RFC, mainly because PHP developers are the ones that would suffer by these configurability on a daily basis. I ended up with a YES vote because when considering STH or nothing at all, I prefer to have some. The bigger WTF is perhaps that moving forward one has no idea just what a third party library is using internally. A case has been made that this does not matter since calling that library from a non-strict site will simply work as now, but in that case the library is not designed to handle non-strict input. It assumes that the strict check happens, where a well designed 'weak' library will be handling the edge cases properly. It not simply a matter of is this file strict or not? but rather what happens when I pass the wrong data?. If I've understood the RFC's correctly, your point is moot. With any scalar type hints, a library will not be able to tell how it is being called. All it knows is that it has received an int, string, float, or boolean where it has asked for one. A library written in weak or strict mode will have no bearing on its public API. This is the case with all of the STH RFCs. So no, a weak mode library is not better off. It is actually worse off because it has more edge cases where things could go wrong (internally), while a strict library will not function at all until the edge cases are actually taken care of. As far as being a user of the library itself, the strictness or weakness of the library code is irrelevant. You can use a weak library in strict mode, and the library would never know or care. if you decide to make all your own code strict, you're not changing the behavior of the library. If you make all your own code weak, you're not changing the behavior of the library. Even if you strips out all the declare strict statements, it will not change the behavior of the library (except in the case where the code was broken and wasn't even working previously!). I think the best way to explain the dual mode RFC is to think of it like this: Imagine PHP threw a COERCIBLE_TYPE_MISMATCH notice whenever you pass the wrong type to a function. In weak mode, the type gets coerced, the notice is ignored, and we truck along as if nothing happened. Strict mode is basically where you've set up a custom, per-file error handler where COERCIBLE_TYPE_MISMATCH notices are turned into fatal errors. It is your code that decides which error handler to use. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On 16 March 2015 at 11:49, Pavel Kouřil pajou...@gmail.com wrote: Seriously, think about it for a while - when some setting that changes how code behaves was a good idea? The problem is that there are two irreconcilable camps - some people want weak STHs, other people want strict STHs. This RFC gives both camps what they want, at the cost of having the dual mode. I personally would prefer a single mode, with strict STHs but I can see that would piss off the other camp. And so to me, this RFC even with the ickiness of the setting, is an an acceptable cost to giving both sides what they want. Oh, and people who don't want to use scalar type hints at all, can still continue to not use scalar type hints, and their code will continue to keep working. Anyone who is voting no, isn't doing so because they are missing out on a feature, they're doing it to block other people from getting what they want in PHP, which is just a terrible way to vote. And if the strict camp are wrong and strict scalars are just not used by a large proportion of the PHP community, it would be trivial to remove support for the strict mode in a future version of PHP, as all code that runs in strict mode, will automatically work in weak mode. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, 16 Mar 2015, Yasuo Ohgaki wrote:
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:
On Mon, 16 Mar 2015, Xinchen Hui wrote:
On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com wrote:
On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
is that right?
You got the answer but one thing bothers me a lot right now.
How did you vote against this rfc while missing the core point
of it (after actually having a strict mode)?
as I said,
acutaly, I believe in most applications, they will still keep this off..
so why we introduce such thing?
I don't like strict_types at all..
To be frank, I don't think I don't like this is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the declare *syntax*, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
*best* bet, I can only vote yes.
Are you sure on your bet?
The bet refered to having type hints at all, ever.
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
a.php:
?php
require lib.php;
foo(123); // will work
?
b.php:
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
This behavior is unacceptable.
Why? The foo() function's $a variable is going to be an int, or the
function isn't called due to strict mode. There is no safety concern
for the value of $a.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should.
And it does - the result in foo() is the same.
Otherwise, all kinds of unexpected for lib.php and it's users may
happen.
You're mistaken. There is *NO* difference in the body of the foo()
function whether you have strict_types on (second example), or off
(first example).
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] In Operator
On 16/03/15 09:14, Nikita Nefedov wrote: There are composer [1] and pickle [2]. Please refrain from your over-frequent comments in this mailing list before doing research on the subject, you tend to create an informational noise when you do this. So it is now official PHP policy that we should be using third party facilities. Is FIG included in that? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, 16 Mar 2015, Yasuo Ohgaki wrote: On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye pierre@gmail.com wrote: On Mar 16, 2015 6:46 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz den...@birkholz.biz wrote: Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki: Caller _must_ satisfy callee requirements. This is simple principle to write a secure code. With this RFC, caller overrides security related setting. This means scripts that are prepared for type safety is ignored and it leads security breach. That's not true. The caller does not override any security setting. The receiving function (callee) will *always* get the type they declared. *That* is important for security. When I first saw Andrea's v3, I was also of the opinion that it should be the callee that controls whether the type hints should be strict or not. But then I realized that it *does not matter*, as the callee will get the right type regardless. Allowing the caller to decide whether it throws an error or not, is irrelevant to any sort of security. Realizing that it didn't matter, made me change my no vote to yes. I thought majority of us see the benefit of StrictSTH over this RFC. You're right about it. This RFC will have serious consequence. We made mistake with safe_mode. The main reason it failed is it did not force caller to have responsibility to make it work as it should. This RFC does the same for how declare(strict_types=1) works. Aren't we learned from safe_mode lessons? I am not sure why you mention safe_mode as this has absolutely nothing to do with scalar type hints. Not feature wise, not implementation wise. safe_mode, first of all, was a global INI setting. The developer couldn't turn it off easily. That was probably at least 80% of the pain. The second part was the name, as it indicated that it made your scripts safe: It didn't. STHv5 does not suffer from either issue — developers can pick and choose the best solution for *them* (give them some credit, most developers are actually smart!). Library authors always get the right type if they type hint, which is *their* main pain point. And the type names have always already been used for casts anyway, and don't include safe in their name. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On 16/03/2015 11:49, Pavel Kouřil wrote:
it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the intent is the same - a switch changing how code
behaves.
ini_set('memory_limit', 10); also changes how your code behave, but it's
global so that can be problematic.
die; changes how your code behave, but you can fix it if it doesn't do
what you want in your file.
Code has meaning and therefore code changes what the program does. I
don't think that's really a problem.
When I talked about the Dual Mode with some friends who are userland
PHP devs (either current or former, because they switched to other
stuff), none of them called the Dual Mode a great idea. The responses
I got were mostly along the lines of wow, this seems really weird to
WTF are those developers smoking. Everyone of them (sure, ~10 people
isn't really representative number) said that they think PHP needs
STH, but not this Dual Mode stuff.
Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?
All your friends can happily ignore strict mode and no sysadmin can
enable it as it is per-file. Those of us that do understand it and might
want to use it can do so, and if your friends eventually go beyond the
this seems really weird phase (it *is* weird because it's an uncommon
approach to have both strict and non-strict in one language, but that
doesn't necessarily mean it's bad) maybe they'll want to use it too some
day. Or perhaps they'll need to start smoking.
Cheers,
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP apache2handler virtual() function
Hi, working on bug 68486 I had a look at the apache2handler virtual() function. This function, as vaguely documented, is intended to make an Apache subrequest, without terminating the currently running request, i.e. run whatever is behind a different URI (given as an argument to virtual(). The subrequest does NOT run in a fresh interpreter. It uses whatever state the interpreter is in when virtual() gets called, and any modification to the interpreter state made by the subrequest, will persist after virtual() returns. i.e. when it works at all. With Apache 2.4 the ap_rflush() in zif_virtual() terminates the currently running main request, in my testing, resulting in a completely crashing apache. This might be remedied, though. At the moment, as part of my efforts to fix bug 68486, I have modified things to that the PHP interpreter is NEVER reentered. virtual() continues to work, but only with URIs that do not again enter the apache2handler. First question here: would this be an acceptable bugfix? Furthermore, I have a working prototype of changing the behaviour of virtual() in the following way: _remember_ which subrequest should be made, but then only really make it when the current request ends (php_handler() in the apache2handler SAPI has deconfigured the interpreter). Done this way, there is no mixing up of interpreter state, neither for the initial request, nor for the subrequest made (which does not risk running into duplicate function / constant definitions and all other kinds of fun). The prototype I have, adds a second, long options argument to the virtual() function, with bit 1 indicating the new behaviour should be used, as just described. The second question would be, whether this new behaviour would be a good thing to have. The third question would be, make this new behaviour the default, or optional with a second virtual() argument. Personally I would simply switch to the new behaviour, as the old one does not make sense to me, and adjust the documentation accordingly. But apparently the function has been available for over 10 years, so opinions might differ... best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Official position in PHP on PEAR?
We all have established ways of working, and my own is based on SUSE as the core OS having switched around a little over the last few years and simply ended up back with what is simply 'comfortable'. I can control the remote servers without a problem and keep them up to date security wise via the SUSE repo's. Managing things not part of the distribution is a problem. ALL of the infrastructure running in production is standard distro, so nginx, PHP and the secondary libraries all install from that. My site code then simply overlays that base. Since PEAR is part of that suite it would be nice if it was up to date and while I HAVE taken the time in the past to push fixes for e_strict and other minor bugs, none of those submissions have ever been accepted, so have to be maintained on the side. composer or pickle do not form part of the SUSE distribution so I have never bothered trying to incorporate them as what I have works. I have to manually build missing extensions such as imagick but that all works with the 'SUSE' layout of directories once one has the right build configuration. If PEAR is no longer 'official policy' is there any mechanism to replace it with alternate packages managed via composer and make that the 'official' way of adding userland code modules. So that distributions have an alternative 'official' mechanism to replace what seems now to not be wanted? I did find some threads on 'is PEAR dead' ... from 2003! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On 16 March 2015 at 09:05, Xinchen Hui larue...@php.net wrote: Hey: I don't like strict_types at all.. And you would never be forced to use them. But you're voting against allowing anyone else to use them. :-( cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 7:32 PM, Xinchen Hui larue...@php.net wrote: Hey: On Mon, Mar 16, 2015 at 7:18 PM, Derick Rethans der...@php.net wrote: On Mon, 16 Mar 2015, Xinchen Hui wrote: On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com wrote: On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote: that means, I need to add a lots of (int) while I try to call a function in a library which is not written by myself. is that right? You got the answer but one thing bothers me a lot right now. How did you vote against this rfc while missing the core point of it (after actually having a strict mode)? as I said, acutaly, I believe in most applications, they will still keep this off.. so why we introduce such thing? I don't like strict_types at all.. To be frank, I don't think I don't like this is a terribly good reason to vote against (or for something). What is important is how many people would actually benefit from a feature, without it causing issues for others. I am certainly no fan of the declare *syntax*, but I do know, from talking at conferences that many many developers would like to see scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and I think they just want a weak type hintings(PHP is a weak type language).. not strict types. especially not a dual mode, switch on/off by a declare line.. it looks so ugly to me.. strict (mode 2). It even caters for people that don't want to use them at all, as they can simply not use them. I also know, that without a dual mode, it seems very unlikely for scalar type hints to make it into PHP 7, and I don't think that is what users want. As this is our *best* bet, I can only vote yes. I understand your choice, but for me, as a six year PHP user. I can see how strict types can benifit me.. can not the only usage I can image is, turn on it in developer env to clean types passing, and turn off in produce env for safety(in case I forget to cast some types from $_GET $_POST). which is definitlely can be done by a extension, or hook.. thanks cheers, Derick -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:
To be frank, I don't think I don't like this is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the declare *syntax*, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
*best* bet, I can only vote yes.
Are you sure on your bet?
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
a.php:
?php
require lib.php;
foo(123); // will work
?
b.php:
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and
it's
users may happen.
When called from a.php, foo() will get and int(123), this is exactly what
is expected. Author of a.php acknowledges that all arguments in fcalls
from this file will be converted to appropriate types, this is basically
how all our internal functions work currently and it's perfectly
acceptable. But if you don't want this kind of type juggling then you
opt-in strict types. This is basically as easy as it gets, I don't see any
way to make it simpler. There's nothing to evolve in this RFC, it covers
pretty much everything and the idea of allowing for caller to make a
decision is, in my opinion, a great win in this situation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE][RESTART] Strict Argument Count On Function Calls
On 16 March 2015 at 02:31, Marcio Almada marcio.w...@gmail.com wrote:
There was no need to update the BC break section. The only minor change was
the addition of the following section:
Yeah, really strong -1 on this one, even after the modification.
Now that the RFC only covers static calling, all of the code it would
pickup could be easily found with a static code analysis tool. For
people who use those already, this RFC has zero benefits and only
downsides.
Having the behaviour of the language change depending on whether
`func_get_args` is in the body of the function is really pretty weird.
Similarly having the behaviour change based on how it's called is
nuts.
function foo() { ... }
$fn = 'foo';
$fn(1); //works
foo(1); //breaks;
If this RFC does pass, it will be an instant addition to phpsadness.com.
Also, the RFC talks a lot about BC breaks but it doesn't even consider
Forward Compatibility. Imagine I have a library that other people use
with a `function foo($x) {}`
I can add other parameters to that function without breaking any code
by using a parameter with a default value i.e. `function foo($x, $y =
null) {}`
Currently, I can also remove the parameter to make the function
signature be `function foo($x) {}` without anything breaking.
This means that people can run their code both against the current
version of the library and the next one, which allows them to test a
new version of a library without having to modify their code, so are
still able to run the current version.
As Marco said, even if it's possible to 'fix' the code that uses this
behaviour - it's a really really useful pattern in the rare case where
it's needed.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 12:49 PM, Pavel Kouřil pajou...@gmail.com wrote: Hello, it's similiar to the safe_mode though. Sure, it's not as bad as INI setting, but the intent is the same - a switch changing how code behaves. When I talked about the Dual Mode with some friends who are userland PHP devs (either current or former, because they switched to other stuff), none of them called the Dual Mode a great idea. The responses I got were mostly along the lines of wow, this seems really weird to WTF are those developers smoking. Everyone of them (sure, ~10 people isn't really representative number) said that they think PHP needs STH, but not this Dual Mode stuff. Seriously, think about it for a while - when some setting that changes how code behaves was a good idea? (IMHO never.) Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I was like that in the beginning when Andrea introduced the declare syntax. But this was because of a fundamental misunderstanding how declare actually works. Now I think it's a brilliant solution to introduce optional strict type hinting. It does not force a user who uses week type hinting to use, care or even know about strict type hinting.
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, 16 Mar 2015 14:50:16 +0300, Yasuo Ohgaki yohg...@ohgaki.net wrote: I already showed real world example how this could be fail. If we need this kind of behavior. I would suggest to have type affinity like SQLite for $_GET/$_POST/$_COOKIE. https://www.sqlite.org/datatype3.html This would work better to work with strict types. I don't see how, given your example, anything would fail. Do you imply that function would get coerced value, but outside of the function you would still have a string and the problem that this string could contain anything? If that's what you were trying to say then I don't consider this as a problem, it's natural flow. If you were to implement type verification in your function on your own you'd get the same results. Perhaps you meant something different? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, 16 Mar 2015, Pavel Kouřil wrote: This RFC will have serious consequence. We made mistake with safe_mode. The main reason it failed is it did not force caller to have responsibility to make it work as it should. This RFC does the same for how declare(strict_types=1) works. Aren't we learned from safe_mode lessons? I am not sure why you mention safe_mode as this has absolutely nothing to do with scalar type hints. Not feature wise, not implementation wise. safe_mode, first of all, was a global INI setting. The developer couldn't turn it off easily. That was probably at least 80% of the pain. The second part was the name, as it indicated that it made your scripts safe: It didn't. STHv5 does not suffer from either issue — developers can pick and choose the best solution for *them* (give them some credit, most developers are actually smart!). Library authors always get the right type if they type hint, which is *their* main pain point. And the type names have always already been used for casts anyway, and don't include safe in their name. it's similiar to the safe_mode though. Sure, it's not as bad as INI setting, but the intent is the same - a switch changing how code behaves. The intent is no where near the same. safe_mode is an evil monster from the depts of a lone sysadm that sees oh it's safe - without a developer having a chance to do anything about it. strict is an option mode that a developer that writes a specific PHP file can opt into. Absolutely not even the same magnitude of evil. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 11:33 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:
On Mon, 16 Mar 2015, Xinchen Hui wrote:
On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com
wrote:
On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
is that right?
You got the answer but one thing bothers me a lot right now.
How did you vote against this rfc while missing the core point of it
(after
actually having a strict mode)?
as I said,
acutaly, I believe in most applications, they will still keep this
off..
so why we introduce such thing?
I don't like strict_types at all..
To be frank, I don't think I don't like this is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the declare *syntax*, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
*best* bet, I can only vote yes.
Are you sure on your bet?
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
a.php:
?php
require lib.php;
foo(123); // will work
?
b.php:
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Yasuo,
The expectation here has been made by the caller (i.e. they’ve put
declare strict=1 in their file). It’s not an expectation of the library.
The library get’s the types it wants (whether they're coerced or not)
regardless of what the caller does, and the caller get’s the benefit of
being able to assure all their parameter types are correct.
/@leedavis81
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 8:44 PM, Nikita Nefedov inefe...@gmail.com wrote:
On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:
To be frank, I don't think I don't like this is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the declare *syntax*, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
*best* bet, I can only vote yes.
Are you sure on your bet?
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
a.php:
?php
require lib.php;
foo(123); // will work
?
b.php:
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.
When called from a.php, foo() will get and int(123), this is exactly what
is expected. Author of a.php acknowledges that all arguments in fcalls from
this file will be converted to appropriate types, this is basically how all
our internal functions work currently and it's perfectly acceptable. But if
you don't want this kind of type juggling then you opt-in strict types.
This is basically as easy as it gets, I don't see any way to make it
simpler. There's nothing to evolve in this RFC, it covers pretty much
everything and the idea of allowing for caller to make a decision is, in my
opinion, a great win in this situation.
I already showed real world example how this could be fail.
If we need this kind of behavior. I would suggest to have type affinity
like SQLite for
$_GET/$_POST/$_COOKIE.
https://www.sqlite.org/datatype3.html
This would work better to work with strict types.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, 16 Mar 2015, Xinchen Hui wrote: And last comment, if there no such declare thing, I will definitely vote yes to this RFC. that's why I want vote no for this, and wait for Bob's Basic STH. That will not be in PHP 7.0 though, as the deadline passed. And I can probably bet on that Basic STH not passing either. So you'll end up with nothing. Thanks! cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP apache2handler virtual() function
On Monday 16 March 2015 10:31:46 Patrick Schaaf wrote: Furthermore, I have a working prototype of changing the behaviour of virtual() in the following way: _remember_ which subrequest should be made, but then only really make it when the current request ends (php_handler() in the apache2handler SAPI has deconfigured the interpreter). A related implementation question: ideally for this new behaviour to be sane, I would like to make, in this case, virtual() not return at all when it thinks it can make the subrequest. (a false return could still happen when apache cannot route the request, I do not change the up-front lookup_uri call). How would I go about doing that, though? i.e. in a PHP_FUNCTION(virtual), how to I in effect do what the EXIT opcode normally does? Patrick -- 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 Nikic,
On 15/03/2015 19:30, Matteo Beccati wrote:
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.
So... I've spent a few hours on the cleanup and I'm still far from
getting a green build.
As you mentioned in the RFC, turning E_STRICT into E_WARNING is going to
be a BC-break for someone, and fixing this one in particular requires
far more effort than a simple search/replace.
For some applications it means heavy refactorings to ensure that all the
inherited methods have a compatible signature. That's enforced even if
the classes were never designed nor are expected to be interchangeable
(e.g. PEAR and its packages, many of which extend PEAR itself), or if
some shortcuts have been made (e.g. function foo() {
parent::foo(BAR); } ).
I agree that it's a wrong usage of inheritance and we shouldn't
encourage it, but maybe an E_NOTICE would be good enough to avoid such
design mistakes.
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] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd dan...@basereality.com wrote: On 16 March 2015 at 11:49, Pavel Kouřil pajou...@gmail.com wrote: Seriously, think about it for a while - when some setting that changes how code behaves was a good idea? The problem is that there are two irreconcilable camps - some people want weak STHs, other people want strict STHs. This RFC gives both camps what they want, at the cost of having the dual mode. I personally would prefer a single mode, with strict STHs but I can see that would piss off the other camp. And so to me, this RFC even with the ickiness of the setting, is an an acceptable cost to giving both sides what they want. Oh, and people who don't want to use scalar type hints at all, can still continue to not use scalar type hints, and their code will continue to keep working. Anyone who is voting no, isn't doing so because they are missing out on a feature, they're doing it to block other people from getting what they want in PHP, which is just a terrible way to vote. And if the strict camp are wrong and strict scalars are just not used by a large proportion of the PHP community, it would be trivial to remove support for the strict mode in a future version of PHP, as all code that runs in strict mode, will automatically work in weak mode. cheers Dan I can't speak for anyone who voted, but personally, if I could vote, I would voted no - not because I don't want to block people from getting what they want, but because I sincerely think that having ANY setting that changes code's behavior is bad in the long run (and that removing the feature might not be really easy, once people realize that the feature is really bad, as people realized with safe_mode and register_globals after few years). I work on multiple projects for multiple clients - some have great code base, some have a bad one. Different typing contexts in different projects isn't going to help anything at all - it will only bring a mental overhead. It's really a shame the other way around wasn't put to vote - to add weak types, and if there's still enough momentum for strict* types, add them with the Dual Mode (although I would love to see PHP without Dual Mode completly). *) I also hate the name strict types, because this behavior is called strongly typed in every other language I stumbled upon; why does PHP have to be a special snowflake? But it's just an aesthetic thing, so it doesn't matter THAT much. PS: Also, I personally don't have a preference between strict or weak typing. I wished from the first moment the Dual Mode was RFC'd that just ONE ruleset would be chosen, and people would adapt to it. (Given the weak nature of PHP, the weak types probably fit more, but I personally could lived with either of those - just not at the same time.) Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function
Hey: On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn petercowb...@gmail.com wrote: On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote: Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Could you add a paragraph or two explaining the reasons for choosing this particular proposal? Some examples of what I would like to read: - why we can't do preg_replace_callback($array_of_regexes, $array_of_callbacks, $subject) array() also could be a valid callback.. (array(clasname, methodname)). - why not preg_replace_callback($array_of_regex_to_callback_pairs, $subject) there are also $limit, $count argument could be used. - why not pass the regex used to the callback, as per Laruence's earlier RFC bc break..(change the callback's signature) And give a few links to historical discussions in the same sort of area? E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq). thanks Any objections? — Best, Wei Dai -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function
Hey: On Mon, Mar 16, 2015 at 11:32 PM, Peter Cowburn petercowb...@gmail.com wrote: On 16 March 2015 at 14:59, Xinchen Hui larue...@php.net wrote: Hey: On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn petercowb...@gmail.com wrote: On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote: Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Could you add a paragraph or two explaining the reasons for choosing this particular proposal? Some examples of what I would like to read: - why we can't do preg_replace_callback($array_of_regexes, $array_of_callbacks, $subject) array() also could be a valid callback.. (array(clasname, methodname)). - why not preg_replace_callback($array_of_regex_to_callback_pairs, $subject) there are also $limit, $count argument could be used. - why not pass the regex used to the callback, as per Laruence's earlier RFC bc break..(change the callback's signature) And give a few links to historical discussions in the same sort of area? E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq). thanks In case my earlier message wasn't clear, I was asking for the RFC itself to be padded out with those sorts of details. The reason being, many (most) people won't be already familiar with the surrounding discussions that have happened previously, or the reasons for the potentially strange-seeming design choices made in this RFC. hmm, yeah, it's better to have these in the RFC. I just replied in case Wei Dai is not familar with these reasons thanks Any objections? — Best, Wei Dai -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()
Hi everyone,
I know it's late for the RFC party, but it looks like some form of STH
is going to land in PHP7. Without reflection support, which is also
missing from return types as far as I know.
That's why I'm resuming this thread, as I still think this is the best
approach. Many do not like ReflectionTypeAnnotation, but that's a
trivial change, if we can agree that the behaviour is correct.
Cheers
On 15/02/2015 10:28, Matteo Beccati wrote:
Hi,
On 14/02/2015 21:23, Matteo Beccati wrote:
On 14/02/2015 16:34, Philip Sturgeon wrote:
On Sat, Jan 31, 2015 at 8:27 PM, Andrea Faulds a...@ajf.me wrote:
I think the more important issue is the conflict with the
ReflectionTypeAnnotation RFC, which proposes something similar to
what was originally part of the Return Types RFC:
https://wiki.php.net/rfc/reflectionparameter.typehint
That's the reflection support I was talking about! I knew there was
something, but I just couldn't find it in the RFCs themself.
I've been playing a little bit with Sara's work (as you might have
noticed if you follow php-cvs - sorry again!) and got it working with
the scalar type hints branch:
https://github.com/mbeccati/php-src/tree/scalar_hints_with_reflection
It's still missing the scalar part and possibly an easy way to get the
class name as Phil suggests.
Thanks to my cats waking me up too early on a sunday morning, I've
rebased Sara's patch to current master and updated it to support return
types:
https://github.com/mbeccati/php-src/commits/reflection.typehint
The new methods are:
* ReflectionFunctionAbstract::hasReturnTypeAnnotation()
* ReflectionFunctionAbstract::getReturnTypeAnnotation()
* ReflectionTypeAnnotation::isInstance()
The latter should fulfil Phil's getClassName() purpose, albeit it's much
more verbose:
function get_name (ReflectionParameter $rp) {
if ($rp-hasTypeAnnotation()) {
$ra = $rp-getTypeAnnotation();
if ($ra-isInstance()) {
return (string) $ra;
}
}
}
I've also added scalar support in:
https://github.com/mbeccati/php-src/commits/scalar_hints_with_reflection
which has:
* ReflectionTypeAnnotation::isScalar()
I believe that both isInstance/isScalar would probably apply to
ReflectionParameter too, unless the old way is supposed to be deprecated.
@Phil I apologise it I hijacked your RFC, but I think that having just
ReflectionParameter::getClassName() falls a bit short IMHO, especially
with return types.
@Andrea, @Sara I hope you don't mind ;)
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][RFC][VOTE] Strict Argument Count On Function Calls
Hi, I had no time to reply all emails since yesterday, but right now we are having a voting with 2 yes votes vs 16 no votes. I think we all agree that the RFC won't pass and I'm withdrawing the RFC for the following reasons: 1. The sooner we end the voting period the better for the PHP time line. Since there is no motives to think the voting will flip, the best attitude seems to be a withdraw. 2. We are having a lot of simultaneous voting right now and some voters care to read all the RFCs. The proposed RFC is long, requires testing etc. As it was already rejected, removing it from the list of RFCs in voting phase might be beneficial to the voting process as it reduces the RFC overload we are having because of the feature freeze. 3. Looking at the ML, there are many controversial points that were raised, a lot of them since yesterday. Weather they are debatable or not, all this controversy during voting phases is a bad thing (look at the scalar type hints drama we had). So it's better to just put this to end and move on. Thanks for the votes, I'll try to reply to the emails anyway whenever necessary :) PS: I don't intend to propose this RFC again in the future as I already have other more important RFCs planned for PHP 7.1 Thanks, Márcio
Re: [PHP-DEV] Voting irregularities
On 16.03.2015 01:08, Jordi Boggiano wrote: On 15/03/2015 22:27, Derick Rethans wrote: On Sun, 15 Mar 2015, Zeev Suraski wrote: 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 Do you know who Kristian is and how instrumental he was in the proliferation of PHP? How can you bring yourself to say he has no clue? I certainly know who he is. I've been around as nearly as long as you've been. Anybody who's only argument is You're turning PHP into Java and basically says we need four more against votes has no clue. I don't care who says it. I agree that past good deeds and contributions should not be a free pass for bad behavior. Not going to discuss the example at hand, but I think it's dangerous to say it's ok he did good in the past. so you think he has an army of lemmings with karma, who can't think but can vote NO? Cheers Jordi Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE][RESTART] Strict Argument Count On Function Calls
Zitat von Marcio Almada marcio.w...@gmail.com: Hi, As promised, the Strict Argument Count RFC vote was restarted: RFC: https://wiki.php.net/rfc/strict_argcount PR: https://github.com/php/php-src/pull/1108 There was no need to update the BC break section. The only minor change was the addition of the following section: https://wiki.php.net/rfc/strict_argcount#about_callbacks_invoke_and_dynamic_calls The voting will close in exactly 14 days counting from now. This is the discussion summary so far http://markmail.org/thread/ol5s2vhw35ac2px3 Acknowledgments to Bob Weinand for offering a practical solution that will help many in case the RFC passes. Thanks, Márcio I voted no because I see the Flexible Interface Implementations mentioned in the RFC a valid and common use case, and the proposed solutions not suitable. You probably haven't found those during real code tests because it's commonly used to migrate or extend APIs. You add a new optional parameter to both the caller and callee of an API, with defensive coding so that both still work if that parameter is not available. This is done to not require new dependency versions. But you won't find those cases if you test complete software stacks, because in the most current version of both modules you will have the new parameter available. Beside that, your testing sample was pretty small. Jan. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dual Mode STH
Thank you Zeev. On 16 March 2015 at 14:35, Xinchen Hui larue...@php.net wrote: Unecessary for everybody, one or two change from no to yes will make it pass. :) Although not necessary, it would reduce the level of drama, which would be a good thing. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: STH and the 3 RFCs
On 16.03.2015, at 15:45, Theodore Brown theodor...@outlook.com wrote: This is a bug in the library. It declares strict mode but passes a value it does not know to be an integer to a method requiring an integer. It can be fixed by simply adding an int type declaration to the constructor or test method. It actually highlights a problem. Anything that says 'int $i' and rejects 1 as a value is defective PHP. You may not like that (I don't), but 20 years of legacy carry a certain weight. K -- Kristian Köhntopp http://google.com/+KristianKohntopp signature.asc Description: Message signed with OpenPGP using GPGMail
[PHP-DEV] RE: STH and the 3 RFCs
Hey, This is a bug in the library. It declares strict mode but passes a value it does not know to be an integer to a method requiring an integer. It can be fixed by simply adding an int type declaration to the constructor or test method. The second example is certainly a programmer error, but the first example could be could considered design by intention to enforce users to pass in the correct argument types. Thanks, Theodore -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: STH and the 3 RFCs
On Monday March 16 at 9:33 am Thomas Punt wrote: Strictly speaking (pun intended), this is not true. A library can easily expose a facade that enforces a user of that library (who is in weak mode) to have to write in strict mode [1]. Once more, this can be done unintentionally [2] because of the caller-deciding semantics. These examples can be further extended into wrapper classes, nested library dependencies, etc. Sure, you could argue that this could easily be turned off by simply removing the top declare() statement of that library, but modifying the library in itself introduces complications - especially when using dependency managers like Composer. [1] https://gist.github.com/tpunt/4830d18d47e2df021c2f [2] https://gist.github.com/tpunt/eecfed2495bdccb73632 This is a bug in the library. It declares strict mode but passes a value it does not know to be an integer to a method requiring an integer. It can be fixed by simply adding an int type declaration to the constructor or test method. Thanks, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: STH and the 3 RFCs
On 16/03/2015 14:45, Theodore Brown wrote: On Monday March 16 at 9:33 am Thomas Punt wrote: Strictly speaking (pun intended), this is not true. A library can easily expose a facade that enforces a user of that library (who is in weak mode) to have to write in strict mode [1]. Once more, this can be done unintentionally [2] because of the caller-deciding semantics. These examples can be further extended into wrapper classes, nested library dependencies, etc. Sure, you could argue that this could easily be turned off by simply removing the top declare() statement of that library, but modifying the library in itself introduces complications - especially when using dependency managers like Composer. [1] https://gist.github.com/tpunt/4830d18d47e2df021c2f [2] https://gist.github.com/tpunt/eecfed2495bdccb73632 This is a bug in the library. It declares strict mode but passes a value it does not know to be an integer to a method requiring an integer. It can be fixed by simply adding an int type declaration to the constructor or test method. Indeed if you enable strict mode you definitely should type-hint all the things *or* validate your inputs. That's a fairly obvious requirement IMO. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function
On 16 March 2015 at 14:59, Xinchen Hui larue...@php.net wrote: Hey: On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn petercowb...@gmail.com wrote: On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote: Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Could you add a paragraph or two explaining the reasons for choosing this particular proposal? Some examples of what I would like to read: - why we can't do preg_replace_callback($array_of_regexes, $array_of_callbacks, $subject) array() also could be a valid callback.. (array(clasname, methodname)). - why not preg_replace_callback($array_of_regex_to_callback_pairs, $subject) there are also $limit, $count argument could be used. - why not pass the regex used to the callback, as per Laruence's earlier RFC bc break..(change the callback's signature) And give a few links to historical discussions in the same sort of area? E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq). thanks In case my earlier message wasn't clear, I was asking for the RFC itself to be padded out with those sorts of details. The reason being, many (most) people won't be already familiar with the surrounding discussions that have happened previously, or the reasons for the potentially strange-seeming design choices made in this RFC. Any objections? — Best, Wei Dai -- Xinchen Hui @Laruence http://www.laruence.com/
[PHP-DEV] Dual Mode STH
All, After much thinking, and despite grave concerns I raised about what transpired in the last 24 hours, I decided to get behind the Dual Mode RFC at this time. I call upon everyone - both people that haven’t yet voted and those who voted no - to do the same so that we ensure that we have STH in PHP 7.0: wiki.php.net/rfc/scalar_type_hints_v5#vote As I’ve said all along, I’m not doing it because I think it’s good, I actually think it’s pretty bad – both in absolute terms and in the precedent for introducing ‘both’ options instead of a single opinionated one. That move is designed to help ensure that we have SOME form of Scalar Type Hints in PHP 7.0, which is clearly what the userbase at large wants. We can revisit casting rules in the future without time pressure, and in general, see how this new feature is accepted and used. Again, I call upon everybody to vote Yes for the Dual Mode RFC to ensure that we have some form of STH in PHP 7.0. Zeev
Re: [PHP-DEV] [RFC][VOTE] Reserve More Type Names in PHP 7
On 16 March 2015 at 04:58, Levi Morrison le...@php.net wrote: Dear Internals, I am tentatively opening the vote on this RFC: https://wiki.php.net/rfc/reserve_more_types_in_php_7 It's a bit tentative because I would prefer to wait until the vote on Anthony's RFC closes tomorrow as there is some overlap in the type names reserved. However, I am unsure if I am allowed to wait one more day, as today is March 15th. In any case, voting is now open. Cheers, Levi Morrison Thanks Levi, I'm glad the aliases were removed, this was the point of contention for me.
[PHP-DEV] Only Vote on Votes Initiated After Registration
While you can easily question the value or motives of Anthony's post about voting irregularities, some simple improvements can be made which are uncontroversial. I consider this a low hanging fruit, like restricting the sale of firearms to people who are clearly drunk. I mentioned on that other thread that the FIG has a rule saying you cannot cast a vote in any vote that was initiated before your membership was activated. That annoyed me a little as I missed out on my vote for PSR-1 and PSR-2, but it's a great way to keep some potential foul play out of things. This may not have ever happened. This will not fix every imagined issue with voting. If it was happening, it would be bad, right? Let's just shove that rule in the wiki and call it done. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Only Vote on Votes Initiated After Registration
Hi all, Am 16.03.2015 um 19:01 schrieb Philip Sturgeon: I mentioned on that other thread that the FIG has a rule saying you cannot cast a vote in any vote that was initiated before your membership was activated. Let's just shove that rule in the wiki and call it done. when we are fixing the low hanging fruits, please directly put in the wiki that the closing time of a vote has to be announced as a UTC time so there is no confusion when a day ends. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
Hi Matthew and all,
On Tue, Mar 17, 2015 at 5:34 AM, Matthew Leverton lever...@gmail.com
wrote:
On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
I think this is important, but not many people realize the importance.
Therefore I created this as a new thread at the last minutes of vote.
...
strict_mode is just controlling errors, then it should be named as
error
controlling directive and raise E_WARNING/E_TYPE or whatever.
Even if what its controlling is error that can be overridden by caller,
yet
calling it strict_types is not correct. Proper name would be something
like raise_type_error.
Let's see how it looks if strict_types is renamed to raise_type_error
...
?php
declare(raise_type_error = 1);
require lib.php;
foo(123); // will give an error
?
I agree that the name doesn't by itself explain the feature, but how
could it possibly? You'd end up with something like:
declare(raise_type_errors_on_parameter_mismatches_when_calling_functions_from_this_file_regardless_of_where_the_functions_are_defined_and_what_the_setting_is_in_other_files=1);
I don't think your suggestion explains the feature any better than
strict_types.
The word strict is not right word for the feature. It should not be used
to avoid
confusions at least.
Anyway, my point is Is everyone feel right about following behavior
regardless of
directive name.
?php
declare(raise_type_error = 1); // declare(strict_types=1) with the
RFC
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(raise_type_error = 1); // declare(strict_types=1) with the
RFC
require lib.php;
foo(123); // will give an error
?
This is the same basically as
?php
error_reporting(E_TYPE);
function foo(int $a) {
// no function call here
}
?
The error_reporting() here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
$old = error_reporting(E_TYPE);
require lib.php;
error_reporting($old);
foo(123); // will give an error
?
Does this make sense?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mar 17, 2015 7:05 AM, Peter Petermann ppeterman...@gmail.com wrote: On March 16, 2015 2:32:39 PM GMT+01:00, Pascal Chevrel pascal.chev...@free.fr wrote: It's too late, Bob's Basic STH missed the schedule for PHP 7, it was proposed way too late and the coercive STH RFC has just zero chance to pass, it's too much of a BC break for everybody. The dual mode STH is the only chance to have something for PHP 7 and remain competitive with Rushing through with an controversial solution, because others didn't make a date seems like such a good plan. No one is dying if STH doesn't make it into 7.0.0. No one will die if php dies. Your point here is totally irrelevant. HHVM, Node.js… that we see people switch to. Baidu switched to HHVM, Wikipedia too, in my country big names switched from PHP to node.js and that was not just for performance reasons, it was also for the features. hhvm offers an alternative php implementation that tries to be compatible, hack(lang) is where you find the differences you are looking for. That said, I don't see the sky falling if people who need a specific feature use another tool. The adoption rate of hack is tiny. As for nodejs, nodejs is a framework, not a language. Javascript does not offer type hints. And if you look at how to compete with nodejs, then what you should be looking at is what needs to be improved with php to allow frameworks like reactphp to work better. How to improve support for non-blocking io. And I dunno, but I don't think that per file settings make the callback-heavy code that's typical for non-blocking stuff better, in fact I'm convinced it will add an additional layer of headache. Zeev himself admitted that we need something for PHP 7. If it is THAT important for PHP 7 (and IMHO it's not) then maybe the timeline for PHP 7 needs to be reevaluated, to make sure all dependencies are the best option and not something rushed in because of ::conflict::. I think you may talk to more developers. I have talked to many, at many confs and UGs (and way too many in the last few weeks, across the pacific), I can count users not looking for STH with one hand.
Re: [PHP-DEV] About declare(strict_types = 1)
On Mar 16, 2015 11:16 PM, Pavel Kouřil pajou...@gmail.com wrote: I can't speak for anyone who voted, but personally, if I could vote, I would voted no - not because I don't want to block people from getting what they want, but because I sincerely think that having ANY setting that changes code's behavior is bad in the long run (and that removing the feature might not be really easy, once people realize that the feature is really bad, as people realized with safe_mode and register_globals after few years). I work on multiple projects for multiple clients - some have great code base, some have a bad one. Different typing contexts in different projects isn't going to help anything at all - it will only bring a mental overhead. So you would have voted no on namespaces?
RE: [PHP-DEV] STH and the 3 RFCs
No, your example would blow up regardless of the caller being in strict mode or weak mode. That was the point in my hypothetical example - the library can decide what mode it wants the user to use (strict or weak) if it wants to. -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 3/16/15 4:03 PM, Anthony Ferrara wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony Huzzah! Huge props to everyone that made this happen, especially Andrea for figuring out how to actually do it and Anthony for impressive perseverance. Does this mean this RFC can/should be withdrawn as redundant: https://wiki.php.net/rfc/reserve_more_types_in_php_7 --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Introduce Type Affinity
Hi all, I had this idea for a long time, but I didn't have time to mention. Since I did mention this idea in basic type hints thread, I've created RFC for it. https://wiki.php.net/rfc/introduce-type-affinity SQLite2 was typeless. All data is stored as text. Type affinity is SQLite3's idea to have native type for better performance. https://www.sqlite.org/datatype3.html PHP may have the same idea for better performance and code. It works well with coercive type or strict type (Not currently proposed one, though) Comments are appreciated! Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] STH and the 3 RFCs
Hi Thomas,
On 16 March 2015 at 20:51, Thomas Punt tp...@hotmail.co.uk wrote:
No, your example would blow up regardless of the caller being in strict mode
or weak mode.
That was the point in my hypothetical example - the library can decide
what mode it wants the user to use (strict or weak) if it wants to.
Sticking with that as a theory...
function foo ($i) {
if(!is_int($i)) {
throw ToysOutOfPramException('I need an integer!');
}
}
We can already do this. Indeed, we do do this. Yes, it *might* be seen
as a dick move employing any sort of trick to push strict type hints
specifically, but being explicit is quite acceptable. I have code
stuffed full of those gems and deployed === checks. So while I
appreciate it looks bad, it's nothing all that new to find people
taking steps to enforce a strict view of acceptable values. There's a
reason why type hints, in some form, have support from the community.
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] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 11:04 PM, Pierre Joye pierre@gmail.com wrote: On Mar 16, 2015 11:16 PM, Pavel Kouřil pajou...@gmail.com wrote: I can't speak for anyone who voted, but personally, if I could vote, I would voted no - not because I don't want to block people from getting what they want, but because I sincerely think that having ANY setting that changes code's behavior is bad in the long run (and that removing the feature might not be really easy, once people realize that the feature is really bad, as people realized with safe_mode and register_globals after few years). I work on multiple projects for multiple clients - some have great code base, some have a bad one. Different typing contexts in different projects isn't going to help anything at all - it will only bring a mental overhead. So you would have voted no on namespaces? You will probably have to try to explain the similiarity between a setting that conceptually changes how language works and namespace. I guess Derick wanted to do so, but his example doesn't make sense and I didn't understand it, tbh. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mar 16, 2015 11:07 PM, Jordi Boggiano j.boggi...@seld.be wrote:
On 16/03/2015 11:49, Pavel Kouřil wrote:
it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the intent is the same - a switch changing how code
behaves.
ini_set('memory_limit', 10); also changes how your code behave, but it's
global so that can be problematic.
die; changes how your code behave, but you can fix it if it doesn't do
what you want in your file.
Code has meaning and therefore code changes what the program does. I
don't think that's really a problem.
When I talked about the Dual Mode with some friends who are userland
PHP devs (either current or former, because they switched to other
stuff), none of them called the Dual Mode a great idea. The responses
I got were mostly along the lines of wow, this seems really weird to
WTF are those developers smoking. Everyone of them (sure, ~10 people
isn't really representative number) said that they think PHP needs
STH, but not this Dual Mode stuff.
Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?
All your friends can happily ignore strict mode and no sysadmin can
enable it as it is per-file. Those of us that do understand it and might
want to use it can do so, and if your friends eventually go beyond the
this seems really weird phase (it *is* weird because it's an uncommon
approach to have both strict and non-strict in one language, but that
doesn't necessarily mean it's bad) maybe they'll want to use it too some
day. Or perhaps they'll need to start smoking.
Btw, I have seen similar comment (to the ones in this thread) about the
windows-like separator for namespaces. Guess what? Nobody cares now. :)
Re: [PHP-DEV] [RFC] Introduce Type Affinity
Hi Yasuo, On Mar 17, 2015 9:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I had this idea for a long time, but I didn't have time to mention. Since I did mention this idea in basic type hints thread, I've created RFC for it. https://wiki.php.net/rfc/introduce-type-affinity SQLite2 was typeless. All data is stored as text. Type affinity is SQLite3's idea to have native type for better performance. https://www.sqlite.org/datatype3.html PHP may have the same idea for better performance and code. It works well with coercive type or strict type (Not currently proposed one, though) Comments are appreciated! I very much appreciate your consistent effort to improve php, at all levels. However I won't comment on this RFC or any further RFCs trying to target 7. My reasoning is that we should now focus on getting it out, in time. I did not agree with the time plan about 7 development but it is what we decided. Let get back to work now.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mon, Mar 16, 2015 at 5:04 PM Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Wow, 156 votes. As a non-internals developer that's been watching this RFC process for quite some time, I'd just like to say thank you. Thank you to you Anthony, and to Andrea, and to the entire collection of dedicated internals developers and community members who worked so hard to make this possible. This is a HUGE win for PHP. I can't wait to start using PHP 7. :) Oh, and Congratulations! - Trevor
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Congratulations Anthony, and to Andrea for her initial proposal. Finally, we have scalar type hints in PHP. PHP 7 is going to be a real game changer! Chris On 16 Mar 2015, at 9:03 pm, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- 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][Accepted] Scalar Type Declarations V0.5
Congratulations Antony, Andrea and (yes) Zeev! Thanks to everyone involved, this is a great step forwards and a perfect wrap for PHP 7.0 RFC proposal freeze :) André On Mar 16, 2015, at 23:05 , Chris Harvey ch...@chrisnharvey.com wrote: Congratulations Anthony, and to Andrea for her initial proposal. Finally, we have scalar type hints in PHP. PHP 7 is going to be a real game changer! Chris On 16 Mar 2015, at 9:03 pm, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- 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][PRE-VOTE] In Operator
Hi!
But I'd like to know from your POV: Does this harm anything?
Depends on what you see as harm. Complicating the language is kind of
harm. Introducing stuff that promotes patterns that are not always best,
and that do a bit too much, and look too much like something in
different languages that does something close, but not exactly that - is
kind of harm. Both kinds are very small, more inconvenience than a
serious problem, and can be easily compensated for by benefits of the
feature, but given we already have all the benefits, I don't see much
point.
I can now with this syntax, write code that directly matches the
cognitive process:
if ($zebra in $zoo) {}
Two things here:
1. If you're looking whether your zoo has a zebra, and you're doing it
by inspecting every inch of your zoo and checking if it doesn't contain
a zebra by any chance, you're running your zoo wrong. I hope this
metaphor is clear :)
2. We don't talk to computers in natural language. For many reasons. So
part of the cognitive process of any programmer is translating his
thoughts into patterns that particular software (we rarely talk to
hardware directly anymore) understands. From that POV, it doesn't matter
too much how exactly bytes that you use to represent it are arranged, as
long as they are not unnecessarily unwieldy. That, of course, is a
matter of opinion, and my opinion is in_array is fine in that regard.
And the newer people to the language often get tripped up on exactly
these kinds of things. Lowering that cognitive barrier to translating
one's thought, to code. I feel is going to be a benefit here.
Frankly, I don't see how that would help. Because with this operator,
you'd have to tell them:
1. It's the same as in_array function, it goes through array and checks
if the element is there.
2. But not exactly - in_array can do non-strict lookup, this one can't.
3. Oh, but instead it also works on strings.
4. Where it is like strstr except it doesn't tell you *where* the
substring is.
5. And if you want to use it like Python's in you shouldn't because
Python's works on keys while ours works on values.
6. And unlike many other languages you can't use it in a loop either.
7. And if you want to write an *efficient* lookup you shouldn't use this
operator at all.
I don't think it is a cognitive simplification.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
Hi all, On Mon, Mar 16, 2015 at 3:03 PM, Matthew Leverton lever...@gmail.com wrote: On Mon, Mar 16, 2015 at 12:55 AM, Xinchen Hui larue...@php.net wrote: That is why I don't see it before (thousand times, too long to read... but not in RFC) It's in the RFC: Whether or not the function being called was declared in a file that uses strict or weak type checking is irrelevant. The type checking mode depends on the file where the function is called. This is one of the point I most dislike. Caller _must_ satisfy callee requirements. This is simple principle to write a secure code. With this RFC, caller overrides security related setting. This means scripts that are prepared for type safety is ignored and it leads security breach. It's just like turning on/off register_globals and allow_url_include by caller. It cannot be right... IMHO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Voting irregularities
Hi! One rule I liked when I was part of the FIG was that people can only vote on votes initiated after they became a member. That stops people signing up simply to vote on an RFC which needs more votes either way. That makes a lot of sense, though I don't think we had much of this issue. First, I don't think we have that many newcomers (as opposed to people lurking and voting only rarely). Second, if somebody wanted to game the system, nothing would prevent him from having their friends join a day before the vote is initiated. The reverse is harder, but only a bit - if one wants to organize a covert downvoting campaign against somebody, discussion period gives enough chance to gather the troops. Of course, as you noted, no evidence this actually happened. But despite that, if this improves the voting procedure, why not. -- Stas Malyshev smalys...@gmail.com -- 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 16:36 schrieb Sebastian Bergmann: Over in Room 11, Michael just pointed out that this could be related to php_stdint.h. Okay, this does not seem to be related to the GCC version but rather to the fact that some int types etc. are not defined on/for my platform. If I use -Dintptr_t=long -Duintptr_t=ulong, for instance, then I can compile PHP (but not link it, but that's another issue). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Reserve even more type hints
The voting period for the Even More type hints reservation RFC is now open. Reminder, any types reserved via this RFC are dependent on at least one of the STH RFCs passing, or Levi's base types reservation RFCs passing as it's silly without at least one of those. https://wiki.php.net/rfc/reserve_even_more_types_in_php_7 Vote will close on the later of 2015-03-29 or the close of all currently open STH RFCs and Levi's base type reservation RFC. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
Hi Yasuo, Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki: Caller _must_ satisfy callee requirements. This is simple principle to write a secure code. With this RFC, caller overrides security related setting. This means scripts that are prepared for type safety is ignored and it leads security breach. that is simply not true! The callee always gets the type it expects. There is no security problem involved here. The only difference is if type conversion rules apply or if an error is raised for a type mismatch. You clearly dislike the RFC (you voted no), that is OK, but don't scream of security bugs that don't exist. If they would exist, all type hint RFCs would have them in general. Greets, Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function
Hey: On Mon, Mar 16, 2015 at 9:40 AM, Wei Dai zxcvda...@gmail.com wrote: Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Any objections? I have no objections on this, since I proposed similar thing before.. I think this is a good addition after we removed /e if you objections raise in couple days, I will merge this. thanks — Best, Wei Dai -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 12:55 AM, Xinchen Hui larue...@php.net wrote: That is why I don't see it before (thousand times, too long to read... but not in RFC) It's in the RFC: Whether or not the function being called was declared in a file that uses strict or weak type checking is irrelevant. The type checking mode depends on the file where the function is called. If it were the other way around, then you'd be correct -- it would be a disaster. -- Matthew Leverton -- 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
Hey: On Mon, Mar 16, 2015 at 2:35 PM, Sebastian Bergmann sebast...@php.net wrote: Am 15.03.2015 um 16:36 schrieb Sebastian Bergmann: Over in Room 11, Michael just pointed out that this could be related to php_stdint.h. Okay, this does not seem to be related to the GCC version but rather to the fact that some int types etc. are not defined on/for my platform. If I use -Dintptr_t=long -Duintptr_t=ulong, for instance, then I can compile PHP (but not link it, but that's another issue). what is the link problems? thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
2015.03.16. 4:18 ezt írta (Philip Sturgeon pjsturg...@gmail.com): One rule I liked when I was part of the FIG was that people can only vote on votes initiated after they became a member. That stops people signing up simply to vote on an RFC which needs more votes either way. I'm not saying that happened, but a simple rule saying You cannot vote on any RFC started before you signed up should not be considered controversial by anyone. While I think that this wouldn't satisfy everybody, but I do think that nobody would be against this. Please make a new thread for this, and I will be looking into patching it into wiki.
Re: [PHP-DEV] [RFC VOTE] Generator Return Expressions
Le 09/03/2015 17:50, Daniel Lowrey a écrit : I'd like to announce voting for the Generator Return Expressions RFC: https://wiki.php.net/rfc/generator-return-expressions#vote Hi, After discussing this RFC with other people at AFUP, it seems we (even if not many of us did express themselves on this matter) are +1. Basically, adding one information that doesn't count in the iterator and acts as some kind of final value could be interesting. Thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- 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 16.03.2015 um 07:41 schrieb Xinchen Hui: what is the link problems? http://pastebin.com/Tk1kaipQ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
Hi Dennis,
On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
Caller _must_ satisfy callee requirements. This is simple principle to
write a secure code.
With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is ignored and it leads security
breach.
that is simply not true! The callee always gets the type it expects.
There is no security problem involved here. The only difference is if
type conversion rules apply or if an error is raised for a type mismatch.
You clearly dislike the RFC (you voted no), that is OK, but don't scream
of security bugs that don't exist. If they would exist, all type hint
RFCs would have them in general.
Not only Java/etc programmers but also PHP programmers will assume type
safety by types.
Programmers assume integer type data is safe once it passes as integer type
parameter.
I'm sure PHP programmer do assume the same thing.
I posted bad code
?php
function check_num_range(int $num) { if ($num 0 || $num 100)
trigger_error('Invalid range'); }
// Somewhere far from function definition.
$num = $GET['num'];
// Somewhere far from $num definition.
check_num_range($num); // Trying to check validity, int and range.
echo 'You have '.$num. ' now br /'; // But $num could have any string.
//
check_num_range((int)$num) wouldn't help also.
?
Caller controlled strict typing makes this worse... i.e.
?php
declare(strict_types=1);
// We are safe since $num is strictly int. Callee has responsibility to
pass valid int . (But it's not)
function check_num_range(int $num) { if ($num 0 || $num 100)
trigger_error('Invalid range'); }
?
Setting register_globals=On while callee script assumes
register_globals=Off is bad thing to do.
Similar argument applies to declare(strict_types=1) also.
As I suggested in other thread, we are better to sit down and make
reasonable decision.
It's not religion, but technical issue. We can reach reasonable consensus
if we try to. If we
cannot, it is better to introduce weak type hint only for the time being.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] RE: timeou handling
On Mon, March 16, 2015 18:17, Dmitry Stogov wrote: If I see the results properly, it makes bout 5% improvement. Right? Definitly makes sense to commit. Let me know when you finish testing, or like me to commif this as is. I've just pushed your patch along with some tests I did to ensure functionality. The tests are not narrowed to Windows, so this should help for the further development. With the perf - yeah, about 5% speedup is like the best time I saw during the perf test. Previously execute_ex was checking for EG(timed_out) on every possible iteration even though it didn't always need it. Now only the relevant opcode handlers are involved in this check, which tells that difference. Despite a thorough testing, it still can be that the EG(timed_out) check is missing somewhere, so anyone seeing it please report. Thanks. Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
