Re: [PHP-DEV] PHP 5.4.33 RC1 = mod_proxy_fcgi still broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 09/09/2014 07:54, Stas Malyshev a écrit : Hi! So what is the resolution for this? Should we roll back the fix, implement the new one and have one more RC, do something else? Sorry, it seems I have miss your question :( As David Zuelke said, this is another fix, so no regression. The big issue I see, is the news entry: . Fixed #65641 (PHP-FPM incorrectly defines the SCRIPT_NAME variable when using Apache). (David Zuelke) And 65641 is not fixed. Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQRTD0ACgkQYUppBSnxahjavgCgw7GW0MYikE9Q26On64rxo1GO cdcAn0mDqaWclVT2caJ/2abz950zZFRY =7cnp -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.33 RC1 = mod_proxy_fcgi still broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 11/09/2014 09:16, Remi Collet a écrit : Le 09/09/2014 07:54, Stas Malyshev a écrit : The big issue I see, is the news entry: . Fixed #65641 (PHP-FPM incorrectly defines the SCRIPT_NAME variable when using Apache). (David Zuelke) Should probably be: . Fixed #67606 (FPM with mod_fastcgi/apache2.4 is broken) -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQRTR8ACgkQYUppBSnxahgRhACgmrK+k8SmZGfkwXTfuW6LMXN2 KBQAn0HjOgBzeWMOGXtS2J5tCQxuQ+kA =xzzJ -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Fix list() behavior inconsistency
Hi, Please take a look and make your opinion. https://wiki.php.net/rfc/fix_list_behavior_inconsistency This inconsistency might be interpreted like a bug, but fixing it might break existing PHP code (at least my attempt to fix it in documented way broke few phpt tests). Thanks. Dmitry.
Re: [PHP-DEV] make casts more strict in PHP 7
On 11 September 2014 04:02:43 GMT+01:00, Park Framework
park.framew...@gmail.com wrote:
You know, “int”, “float”, “string” etc. aren’t currently reserved
words.
Well, they are in the context of casts:
$a = (int)'42';
$a = (string)42;
etc
We could add functions, or even make them reserved words and add
internal functions (à la isset), so int(‘2’), float(‘2.0’),
string(‘test’) etc.
How would this be different from what we already have? For the function version
(useful as a callback), we have intval(), strval(), etc
Or perhaps class-like constructors? $a = new int('2'); ? Would kinda
make sense given some people want to add methods to primitive types.
+1
$int instanceof Int
$float instanceof Float
$num instanceof Numeric
$bool instanceof Boolean
$str instanceof String
$array instanceof Array
This makes it possible not to use the is_*() functions.
It is desirable to conduct instanceof fully consistent with behavior
hinting casts, it would be logical and correct.
Just wanted to be able to use these classes (or interfaces) to create
their objects, these objects would pass inspection in hinting casts.
This could cause a lot of confusion. If these constructors are just a new
syntax for type casting, there's no obvious reason to behave differently in
terms of strictness, which is what we were discussing previously. Worse, they
would look like objects, but behave as plain variables (no reference-like
ability to modify the value in place).
Alternatively, these could be special boxed types, which were real objects
acting almost but not quite the same way as the equivalent basic type. Some
languages (e.g. Java) have those, but they're frankly rather confusing, and I'm
not sure what the benefit would be.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove alternative PHP tags
On 10/09/2014 3:32, Andrea Faulds wrote: Some further thoughts after discussing with Tyrael (Ferenc) on IRC. I initially thought that I’m not really against removing them really, but I think we should have a script to convert them first. Because someone, somewhere, is gonna need it. But then I’ve thought more about it. I’m usually OK with certain BC breaks, I just don’t like this specific one. It doesn’t affect me, but, well, I don’t see the point. It doesn’t really help language consistency or anything, (OK, sure, only two sets of delimeters now, but it’s not a big deal like some other things are), and you’ll force people to update every file in their codebase if they’re affected, assuming people who use alternative tags use them everywhere. There’s also a security issue here. If someone uses PHP 7 with a codebase that has these alternative tags, your code is now visible to users instead of the output, which might include configuration details like database passwords or password hash salts. It’s also possible that people won’t notice this is happening if they only used these alternative tags in a few obscure places. I wonder if, really, we might be better off keeping them around and just outputting E_DEPRECATED. If we do get rid of them in 7, we should have 5.7 deprecate them. Maybe it's sufficient to add this as an additional check (sniff) to PHPCompatibility, so we can automate the detection of these tags and their deprecation/removal. It won't auto-convert them, but for the few people using them, an auto-convertion script that works in all cases and never breaks code would be a lot more work to write than those people replacing the tags ;-) Wim -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove alternative PHP tags
On Tue, Sep 9, 2014 at 6:32 PM, Andrea Faulds a...@ajf.me wrote: On 10 Sep 2014, at 01:21, Andrea Faulds a...@ajf.me wrote: Isn’t this a bit of a needless BC break? Not very nice on people with such codebases. It’s also worth pointing out that people might be using these to get around the XML ? issue (granted, you can disable short tags). I’d vote for this if you wrote a convertor script to help people migrate. Otherwise I think we’re just being unfair on people who used these tags. Actually, I’d like to see a Python 2to3-esque tool in general for PHP 7. The easier we make the migration, the more likely people will do it. Some further thoughts after discussing with Tyrael (Ferenc) on IRC. I initially thought that I’m not really against removing them really, but I think we should have a script to convert them first. Because someone, somewhere, is gonna need it. But then I’ve thought more about it. I’m usually OK with certain BC breaks, I just don’t like this specific one. It doesn’t affect me, but, well, I don’t see the point. It doesn’t really help language consistency or anything, (OK, sure, only two sets of delimeters now, but it’s not a big deal like some other things are), and you’ll force people to update every file in their codebase if they’re affected, assuming people who use alternative tags use them everywhere. There’s also a security issue here. If someone uses PHP 7 with a codebase that has these alternative tags, your code is now visible to users instead of the output, which might include configuration details like database passwords or password hash salts. It’s also possible that people won’t notice this is happening if they only used these alternative tags in a few obscure places. I wonder if, really, we might be better off keeping them around and just outputting E_DEPRECATED. If we do get rid of them in 7, we should have 5.7 deprecate them. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think Andrea raises a valid point about BC. I agree that those old tags should go, but I'd suggest we target that removal for PHP 7 and just add a deprecated flag on 5.x. --Kris
[PHP-DEV] Re: Remove alternative PHP tags
Nikita Popov wrote: I've created a small RFC proposing the removal of the alternative PHP opening/closing tags: https://wiki.php.net/rfc/remove_alternative_php_tags It removes % and script language=php and the other variations of asp and script tags. The RFC states: | The alternative PHP tags have never gained any significant degree of | usage. Their usage has been discouraged since forever. Unfortunately, it seems that the PHP manual doesn't mention that all these PHP tags are discouraged. http://php.net/manual/en/language.basic-syntax.phpmode.php only mentions: | As such, while some people find short tags and ASP style tags | convenient, they are less portable, and generally not recommended. I wonder if there are any faithful stats regarding the usage of the alternative PHP tags. I have never seen them in use (I have not even been aware of the script ... tags), but that doesn't mean much. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove alternative PHP tags
Am 10.09.2014 um 03:32 schrieb Andrea Faulds: But then I’ve thought more about it. I’m usually OK with certain BC breaks, I just don’t like this specific one. It doesn’t affect me, but, well, I don’t see the point. It doesn’t really help language consistency or anything, (OK, sure, only two sets of delimeters now, but it’s not a big deal like some other things are), and you’ll force people to update every file in their codebase if they’re affected, assuming people who use alternative tags use them everywhere. There’s also a security issue here. If someone uses PHP 7 with a codebase that has these alternative tags, your code is now visible to users instead of the output, which might include configuration details like database passwords or password hash salts. It’s also possible that people won’t notice this is happening if they only used these alternative tags in a few obscure places. I wonder if, really, we might be better off keeping them around and just outputting E_DEPRECATED. If we do get rid of them in 7, we should have 5.7 deprecate them. Hi, I didn't even know that these tags exist ;-) If you check Github you will see round about 10.000 code results, but most of them are tests (.phpt), example files, duplicate results, and maybe 100 projects that really use them, and I would guess 90% of these projects are rarely used and very old. https://github.com/search?p=1q=%22%3Cscript+language%3Dphp%3E%22ref=searchresultstype=Code Does the removal of those two tags result in a tiny performance boost, or have any other real advantage besides a little less code in php-src? In my opinion we should remove them, but before doing that they should be deprecated for at least a year, and spread the word. I also see the problem of presenting the sourcecode as cleartext to website users. Maybe it makes sense to have a version after the deprecation period which just stops the PHP parser/compiler and stops working on that file, something like a FATAL error without exposing the file content? Maybe there is a way to automatically create Github Issues where one of these tags is found in a repository? I don't know if that's common, but Webhosters and PHP PaaS Providers COULD scan their customers code for these tags and inform them about the potential security problem before they upgrade to PHP 7 (where these tags are removed)? Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 1921 Piscinas espectaculares
--- Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa. http://www.avast.com
