Re: [PHP-DEV] Proposal for better UTF-8 handling
Hello Rouven, the lack of good UTF-8 support is a long topic in PHP and improvement (at least i think) are very welcome at this place! Before I write an RFC I'd like to get some feedback what you think about adding the following functions to PHP 5.6 (possibly more to follow): utf8_is_valid, utf8_strlen, utf8_substr, utf8_strpos, utf8_strrpos, utf8_str_split, utf8_strrev, utf8_recover, utf8_chr, utf8_ord, string_is_ascii. Most of them (exceptions are utf8_chr, utf8_is_valid, utf8_recover and string_is_ascii) are currently written in a way that they emit a warning when they encounter invalid UTF-8 and return with null. This should encourage applications to check their input with utf8_is_valid and either stop further processing or to fall back to utf8_recover to get a valid string. This should improve security since there are attack vectors when malformed sequences get interpreted as another encoding. I'm currently using the multibyte from the mb_ functions and i'm generally happy with it. For me it's no problem with a custom webserver to use this extension. The biggest problem with the extension i had is that there is no each function from the standard string functions available. I think most famous: mb_str_replace Maybe to think off: Why not combine your things with the mb_ extension? For emmiting a warning you could use a configuration either in ini file or calling a function to set it. I would rather like one complete mb/utf-8 lib that even one more. Like you have already written, there are already some out thereand for core i would currently preferr mb_ because they are available since PHP4 and stable.
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. I believe this may have been the behavior at some point; at least date_default_timezone_get change in PHP 5.4 to no longer includes info from the OS. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP5.5 RC2 has been tagged
Hi Internals, Our RC2 of PHP 5.5.0 has been released for testing. It fixes some bugs and improves stability against RC1 code. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. This second RC could be the last one. Depending on bug reports, expect another RC or a stable release to be announced for June 6th. Thank you. Regards Julien and David
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, May 24, 2013 at 12:11 AM, Levi Morrison morrison.l...@gmail.comwrote: The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. I believe this may have been the behavior at some point; at least date_default_timezone_get change in PHP 5.4 to no longer includes info from the OS. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. Thoughts? --Kris
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, May 24, 2013 at 1:16 AM, Kris Craig kris.cr...@gmail.com wrote: On Fri, May 24, 2013 at 12:11 AM, Levi Morrison morrison.l...@gmail.comwrote: The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. I believe this may have been the behavior at some point; at least date_default_timezone_get change in PHP 5.4 to no longer includes info from the OS. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. Thoughts? --Kris Another possible idea would be to make it so that you can specify the date.timezone in configure. This would cause make install to automatically set it in php.ini. That might be useful for folks like Daniel who don't like having to do that extra step of manually editing php.ini to avoid throwing warning errors. --Kris
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote: Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. An estimate of 90% of our users who are actually installing PHP themselves are using distribution packages of PHP and not our sources. They expect `[yum|apt-get|...] install php` to be the whole installation process. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
Hi! As a PHP programmer, I would always expect the file/line to refer to the throw statement that has thrown it last. If I wanted to keep track It is rather surprising that you would expect that as a PHP programmer, since it never worked this way in PHP, and no PHP code works this way either. Also, throwing new exception with previous is not the same as throwing the same exception twice. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On 2013-05-24 10:34, Johannes Schlüter wrote: On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote: Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. An estimate of 90% of our users who are actually installing PHP themselves are using distribution packages of PHP and not our sources. They expect `[yum|apt-get|...] install php` to be the whole installation process. Yet it's not uncommon for yum/apt-get/whatever to ask for input (like mentioned MySQL asking for root password). --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for better UTF-8 handling
On Fri, May 24, 2013 at 3:17 AM, Rouven Weßling m...@rouvenwessling.dewrote: Hi Internals! First let me introduce myself, my name is Rouven Weßling, I'm a student at RWTH Aachen University and I'm one of the maintainers of the Joomla! Framework (née Platform). I've been following the internals list for a few months and started brushing of my C skills for the past couple of months so I can start contributing. To me one of the most annoying things about working with PHP is the (lack of) unicode support. In Joomla! we've been discussing switching from PHP UTF-8 to Patchwork UTF-8 for our needs of handling UTF-8. Both are libraries abstracting the multibyte extension and supplementing it with a number of functions. They also provide userland replacements for when multibyte is not available (Patchwork will also use iconv and intl if available). All of this is a huge pain. To ease this situation I'd like to make a new start at better unicode support for PHP, this time focusing on UTF-8 as the dominant web encoding. As a first step I'd like to propose adding a set of functions for handling UTF-8 strings. This should keep applications from implementing these algorithms in PHP (also many of these are quite a bit faster, see benchmark results below). Once the algorithms are in place I'd like to look into creating a class for unicode strings and eventually Python like unicode literals. Before I write an RFC I'd like to get some feedback what you think about adding the following functions to PHP 5.6 (possibly more to follow): utf8_is_valid, utf8_strlen, utf8_substr, utf8_strpos, utf8_strrpos, utf8_str_split, utf8_strrev, utf8_recover, utf8_chr, utf8_ord, string_is_ascii. Most of them (exceptions are utf8_chr, utf8_is_valid, utf8_recover and string_is_ascii) are currently written in a way that they emit a warning when they encounter invalid UTF-8 and return with null. This should encourage applications to check their input with utf8_is_valid and either stop further processing or to fall back to utf8_recover to get a valid string. This should improve security since there are attack vectors when malformed sequences get interpreted as another encoding. You can find the code I've written so far here: https://github.com/realityking/pecl-utf8 You can find benchmark results here: http://realityking.github.io/pecl-utf8/results.html Best regards Rouven We already have a lot of functions for multibyte string handling. Let me list a few: * The str* functions. Most of them are safe for usage with UTF8. Exceptions are basically everything where you manually provide an offset, e.g. writing substr($str, 0, 100) is not safe. substr($str, 0, strpos($str, 'xyz')) on the other hand is. * The mb* functions. They work with various encodings and usually make of of character offsets and lengths rather than byte offsets and lengths. They are not necessary most of the time, but useful for the aforementioned substr call with hardcoded offsets. * The Intl extension. This give you *real* unicode support, as in collations, locales, transliteration, etc. * The grapheme* functions which are also part of intl. The work with grapheme cluster offsets and lengths. Anyway, my point is that just adding *yet another* set of string functions won't solve anything, just make things even more complicated than they already are. I'm not strictly opposed to adding more functions if they are necessary, but one has to be aware of what there already is and how the new functions will integrate. Nikita
Re: [PHP-DEV] Cannot call constructor
On 24 May 2013 13:11, Ferenc Kovacs tyr...@gmail.com wrote: On Thu, May 23, 2013 at 11:32 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Right now, to avoid this situation, you have to do: if (method_exists(get_parent_class(), '__construct')) parent::__construct(); If you don't check for the method existing, you get: Fatal error: Cannot call constructor ... This makes a lot of sense. I think we also discussed this idea some time ago, but it didn't go anywhere that time... last time it was discussed on the list: http://www.mail-archive.com/internals@lists.php.net/msg50504.html to summarize it: Etienne was arguing that for the concrete example (Spl classes) it would be better to make sure that the object is properly initialized so having a constructor in the spl classes. Anthony was the only one who was against the idea of removing the error when you call a parent constructor which doesn't (explicitly) have one. Otherwise everybody else seemed to agree with the above change and only the implementation was discussed: - we should remove the error completelly - we should make the error less serious (please don't do this) - we should always create a common ancestor for every class by default which have an empty constructor/destructor - we should always create an empty constructor/desctructor for every class without it. So maybe we could discuss this and based on the feedback create an rfc (with or without a vote for the alternative implementations). Hi. I'm not an expert here, so just thinking out loud ... If a theoretical \PHP\baseclass can have empty __construct()/__destruct(), what about the other magic methods? OK, I suppose cascading some of the magic methods to a parent and having a null parent at the very very bottom of the heap sounds useful. But I'm not totally sure. Is there much/any need for a true base class that ALL classes will extend from, including those in extensions. Richard. -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
Also, throwing new exception with previous is not the same as throwing the same exception twice. Correct, but I've personally never thrown the same exception twice. The only times I've thrown exceptions from catch blocks is to provide a better exception or perhaps to abstract away something in the implementation. For instance, if I hit a PDO exception in my data access then I'll catch it somewhere higher in the structure and throw a GatewayException instead. Likewise, if the data was coming from The Cloud and I couldn't access it for some reason I'd throw the GatewayException. This way when someone uses the gateway the implementation doesn't leak. This is the only time I've thrown exceptions in a catch block. This is an interesting 'bug' or 'feature' or whatever you want to call it. I wouldn't say the current way is wrong, but a naive approach would have some interesting issues as well. More than anything I think we just need to decide what we want the behavior to be a document the resulting quirks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
Hi. I'm not an expert here, so just thinking out loud ... If a theoretical \PHP\baseclass can have empty __construct()/__destruct(), what about the other magic methods? OK, I suppose cascading some of the magic methods to a parent and having a null parent at the very very bottom of the heap sounds useful. But I'm not totally sure. Is there much/any need for a true base class that ALL classes will extend from, including those in extensions. it was discussed in the linked thread, personally I agree that those are different both in intention and implementation, so shouldn't affected by this change. ps: for example having an empty __sleep() or __wakeup implementation would be entirely differrent that one would expect. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Cannot call constructor
Sure the default implementation would have to be identical to the behavior of not defining one. I believe the best way to solve these issues is by having an implicit base class. To some extent, that means BC breaks though. On Fri, May 24, 2013 at 5:22 PM, Ferenc Kovacs tyr...@gmail.com wrote: Hi. I'm not an expert here, so just thinking out loud ... If a theoretical \PHP\baseclass can have empty __construct()/__destruct(), what about the other magic methods? OK, I suppose cascading some of the magic methods to a parent and having a null parent at the very very bottom of the heap sounds useful. But I'm not totally sure. Is there much/any need for a true base class that ALL classes will extend from, including those in extensions. it was discussed in the linked thread, personally I agree that those are different both in intention and implementation, so shouldn't affected by this change. ps: for example having an empty __sleep() or __wakeup implementation would be entirely differrent that one would expect. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Etienne Kneuss http://www.colder.ch
Re: [PHP-DEV] Proposal for better UTF-8 handling
On Fri, May 24, 2013 at 3:09 PM, Nikita Popov nikita@gmail.com wrote: On Fri, May 24, 2013 at 3:17 AM, Rouven Weßling m...@rouvenwessling.de wrote: Hi Internals! First let me introduce myself, my name is Rouven Weßling, I'm a student at RWTH Aachen University and I'm one of the maintainers of the Joomla! Framework (née Platform). I've been following the internals list for a few months and started brushing of my C skills for the past couple of months so I can start contributing. To me one of the most annoying things about working with PHP is the (lack of) unicode support. In Joomla! we've been discussing switching from PHP UTF-8 to Patchwork UTF-8 for our needs of handling UTF-8. Both are libraries abstracting the multibyte extension and supplementing it with a number of functions. They also provide userland replacements for when multibyte is not available (Patchwork will also use iconv and intl if available). All of this is a huge pain. To ease this situation I'd like to make a new start at better unicode support for PHP, this time focusing on UTF-8 as the dominant web encoding. As a first step I'd like to propose adding a set of functions for handling UTF-8 strings. This should keep applications from implementing these algorithms in PHP (also many of these are quite a bit faster, see benchmark results below). Once the algorithms are in place I'd like to look into creating a class for unicode strings and eventually Python like unicode literals. Before I write an RFC I'd like to get some feedback what you think about adding the following functions to PHP 5.6 (possibly more to follow): utf8_is_valid, utf8_strlen, utf8_substr, utf8_strpos, utf8_strrpos, utf8_str_split, utf8_strrev, utf8_recover, utf8_chr, utf8_ord, string_is_ascii. Most of them (exceptions are utf8_chr, utf8_is_valid, utf8_recover and string_is_ascii) are currently written in a way that they emit a warning when they encounter invalid UTF-8 and return with null. This should encourage applications to check their input with utf8_is_valid and either stop further processing or to fall back to utf8_recover to get a valid string. This should improve security since there are attack vectors when malformed sequences get interpreted as another encoding. You can find the code I've written so far here: https://github.com/realityking/pecl-utf8 You can find benchmark results here: http://realityking.github.io/pecl-utf8/results.html Best regards Rouven We already have a lot of functions for multibyte string handling. Let me list a few: * The str* functions. Most of them are safe for usage with UTF8. Exceptions are basically everything where you manually provide an offset, e.g. writing substr($str, 0, 100) is not safe. substr($str, 0, strpos($str, 'xyz')) on the other hand is. * The mb* functions. They work with various encodings and usually make of of character offsets and lengths rather than byte offsets and lengths. They are not necessary most of the time, but useful for the aforementioned substr call with hardcoded offsets. * The Intl extension. This give you *real* unicode support, as in collations, locales, transliteration, etc. * The grapheme* functions which are also part of intl. The work with grapheme cluster offsets and lengths. Anyway, my point is that just adding *yet another* set of string functions won't solve anything, just make things even more complicated than they already are. I'm not strictly opposed to adding more functions if they are necessary, but one has to be aware of what there already is and how the new functions will integrate. Nikita did you just forgot the pcre functions with the /u modifier?!?! :P -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Cannot call constructor
On Fri, May 24, 2013 at 5:26 PM, Etienne Kneuss col...@php.net wrote: Sure the default implementation would have to be identical to the behavior of not defining one. agree I believe the best way to solve these issues is by having an implicit base class. that would also solve the I want to typehint objects problem. To some extent, that means BC breaks though. by BC break you mean the name of the implicit base class? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Proposal for better UTF-8 handling
On 24 May 2013 08:26, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, May 24, 2013 at 3:09 PM, Nikita Popov nikita@gmail.com wrote: We already have a lot of functions for multibyte string handling. Let me list a few: * The str* functions. Most of them are safe for usage with UTF8. Exceptions are basically everything where you manually provide an offset, e.g. writing substr($str, 0, 100) is not safe. substr($str, 0, strpos($str, 'xyz')) on the other hand is. * The mb* functions. They work with various encodings and usually make of of character offsets and lengths rather than byte offsets and lengths. They are not necessary most of the time, but useful for the aforementioned substr call with hardcoded offsets. * The Intl extension. This give you *real* unicode support, as in collations, locales, transliteration, etc. * The grapheme* functions which are also part of intl. The work with grapheme cluster offsets and lengths. Anyway, my point is that just adding *yet another* set of string functions won't solve anything, just make things even more complicated than they already are. I'm not strictly opposed to adding more functions if they are necessary, but one has to be aware of what there already is and how the new functions will integrate. Nikita did you just forgot the pcre functions with the /u modifier?!?! :P And that's without even touching PECL. :) I agree with Nikita — I'm not against adding more Unicode/charset handling functions if they make sense (and I haven't looked at the code for this particular proposal yet), particularly if they'd be part of a default build, but enough water has hopefully passed under the bridge since the PHP 6 days that it might be time to canvass ideas on a less piecemeal approach to character set handling and internationalisation for PHP 5.5+1 or PHP 5.5+2. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
On Fri, May 24, 2013 at 5:32 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, May 24, 2013 at 5:26 PM, Etienne Kneuss col...@php.net wrote: Sure the default implementation would have to be identical to the behavior of not defining one. agree I believe the best way to solve these issues is by having an implicit base class. that would also solve the I want to typehint objects problem. To some extent, that means BC breaks though. by BC break you mean the name of the implicit base class? No, I was more referring to the fact that people might be relying on the hierarchy to be bounded by their own classes, and checking for their roots using i.e. class_parents/reflection. If we introduce a class and force it as parent of every userland root classes, you can always find existing code to break in non-trivial ways :) It seems acceptable to me though, given the progress we would make with this change. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Etienne Kneuss
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
On Fri, May 24, 2013 at 10:44 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! As a PHP programmer, I would always expect the file/line to refer to the throw statement that has thrown it last. If I wanted to keep track It is rather surprising that you would expect that as a PHP programmer, since it never worked this way in PHP, and no PHP code works this way either. Also, throwing new exception with previous is not the same as throwing the same exception twice. I agree, I think it makes sense to see exceptions as immutable and let new define the line. If you want to rethrow an exception in a different context while keeping track of both, I think chaining them is the better approach: throw new AnotherException(.., 0, $thepreviousexception); -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch
Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e
On 24 May 2013 10:44, Stas Malyshev smalys...@sugarcrm.com wrote: It is rather surprising that you would expect that as a PHP programmer, since it never worked this way in PHP, and no PHP code works this way either. I'm saying that as a PHP programmer because my expectation is not based on how other languages work, it's instinctive (perhaps influenced by what used to be the method's description.) If I call getLine() and I don't think about how other languages handle exceptions, and I don't go out of my way to check the manual to see whether it's been changed since 5.1, what comes to mind is this is going to tell me where the throw occured. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, 24 May 2013, Leszek Krupiński wrote: On 2013-05-23 22:10, Stas Malyshev wrote: The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. You can't, as the OS doesn't give you the timezone identifier in a portable way. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, 24 May 2013, Leszek Krupiński wrote: On 2013-05-24 10:34, Johannes Schlüter wrote: On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote: Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. An estimate of 90% of our users who are actually installing PHP themselves are using distribution packages of PHP and not our sources. They expect `[yum|apt-get|...] install php` to be the whole installation process. Yet it's not uncommon for yum/apt-get/whatever to ask for input (like mentioned MySQL asking for root password). I'm pretty sure apt can read the configuration from their tzdata package to add the correct setting to php.ini: a=`debconf-show tzdata | grep Areas | sed 's/.*\s//'`; b=`debconf-show tzdata | grep Zones/$a | sed 's/.*\s//'`; echo $a/$b However, that is something for distributions to do as each distribution's mechanism is different. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Am 24.05.2013 18:45 schrieb Derick Rethans der...@php.net: On Fri, 24 May 2013, Leszek Krupiński wrote: I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. You can't, as the OS doesn't give you the timezone identifier in a portable way. Couldn´t the default, in the absense of an .ini setting, be to use localtime(), i.e. whatever libc does, with the timezone _identifier_ being some string like OS, System, or Localtime - and we could then also use that identifier in .ini or ini_set to precisely say use the same timezone as all the other libc using programs on this system. best regards Patrick
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, 24 May 2013, Patrick Schaaf wrote: Am 24.05.2013 18:45 schrieb Derick Rethans der...@php.net: On Fri, 24 May 2013, Leszek Krupiński wrote: I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. You can't, as the OS doesn't give you the timezone identifier in a portable way. Couldn´t the default, in the absense of an .ini setting, be to use localtime(), i.e. whatever libc does, with the timezone _identifier_ being some string like OS, System, or Localtime - and we could then also use that identifier in .ini or ini_set to precisely say use the same timezone as all the other libc using programs on this system. Absolutely not, as you can then never convert between that and another zone. This nonsense is what Redhat patches into it as well and it is a BAD idea. You'd have no idea which DST rules are cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
While UTC is not *ideal*, I am failing to see why its not a reasonable default. After all, according to http://us3.php.net/manual/en/function.date-default-timezone-get.php If none of the above succeed, date_default_timezone_get() will return a default timezone of UTC. If people care about dealing with time's in a non-UTC way, it seems to me they they would either A) ensure their server is set to an appropriate timezone (by setting it or bugging their system administrator) or B) ensuring their app calls date_default_timezone_set() in a bootstrap/initialization script (globally) or C) set the timezone in an application context specific way through DateTime::setTimezone(). As far as I can tell, with all standard distribution extensions, there is no other extension that will toss a warning with the default configuration... thus making this the outlier. -ralph On 5/23/13 3:10 PM, Stas Malyshev wrote: Hi! I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a I'm not sure how this follows - CLI is capable of using ini file just like the rest of SAPIs. Why not create it? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
If none of the above succeed, date_default_timezone_get() will return a
default timezone of UTC.
It will still raise a warning, by the way. This is horrible behavior;
I recommend the following:
date_default_timezone_set(ini_get('date.timezone') ?: 'UTC');
This is basically what date_default_timezone_get does as of PHP 5.4
except there is no warning.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] About fileinfo test.mp3
Hi Anatol, I saw your commit 74555e7c26b2c61bb8e67b7d6a6f4d2b8eb3a5f3 added a 4mb mp3 file. Is it possible to create a much smaller mp3 that helps to reproduce the same bug? The file blows up the taball file for the final release, which I hope to keep as small as possible. Thanks in advance, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, May 24, 2013 at 2:40 AM, Derick Rethans der...@php.net wrote: On Thu, 23 May 2013, Daniel Lowrey wrote: I guess my point is that I don't believe default settings should trigger errors. If it's a default setting, it's a default setting. No - you, as an admin, are required to make an informed decision on what you want your timezone to be. There have been way too many bug reports where people had no clue, so now we throw a warning. Sorry, but I fail to see why date.timezone needs special handling. What makes the date.timezone setting so important, that it is the only one which value you are required to set? There are settings that are arguably a lot more important than this, but which do not throw such warnings. E.g., why isn't there a warning for cases where error_reporting is not explicitly specified? I can't count the number of StackOverflow questions caused by bad error_reporting settings and I'm very sure this number surpasses complains about timezones by several orders of magnitude. Yet - of course! - we do no such thing, for it is senseless. After all, there *is* a reason why we have defaults for ini settings. People should only be required to changed them when necessary. Date.timezone should be no exception to this. Nikita
[PHP-DEV] Re: About fileinfo test.mp3
Hi David, On Fri, 2013-05-24 at 23:28 +0200, David Soria Parra wrote: Hi Anatol, I saw your commit 74555e7c26b2c61bb8e67b7d6a6f4d2b8eb3a5f3 added a 4mb mp3 file. Is it possible to create a much smaller mp3 that helps to reproduce the same bug? The file blows up the taball file for the final release, which I hope to keep as small as possible. Thanks in advance, David yep, I'm working on that currently. That file was additionally reported as containing some copyrighted song. Never looked inside though :) . I'll fix that at least by tomorrow. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: About fileinfo test.mp3
Am 24.05.2013 23:38, schrieb Anatol Belski: Hi David, On Fri, 2013-05-24 at 23:28 +0200, David Soria Parra wrote: Hi Anatol, I saw your commit 74555e7c26b2c61bb8e67b7d6a6f4d2b8eb3a5f3 added a 4mb mp3 file. Is it possible to create a much smaller mp3 that helps to reproduce the same bug? The file blows up the taball file for the final release, which I hope to keep as small as possible. Thanks in advance, David yep, I'm working on that currently. That file was additionally reported as containing some copyrighted song. Never looked inside though :) . I'll fix that at least by tomorrow. Regards Anatol Hi, is there a sane way to completely remove that file from the git history? Having a public git mirror might get me into trouble and I am probably not the only one. Also: WTF? Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
Encouraging call super is still not the right way to go about this. As
I said before, even with the changes proposed, there's no way to
*contractually enforce* the call super pattern in this language.
That's why it is and will remain an antipattern. So all you're doing
is allowing people to more easily use the antipattern, instead of (a)
baking auto-super (contractual call super) into the language or (b)
pushing people to use a preferred pattern (Template Method or other).
Template Method in userland is not difficult (lightly tested):
trait templateInitializer {
private $inited;
final public function __construct( $arg1, $arg2 ) {
print __construct in super calling inits...BR;
$this-init( $arg1, $arg2 );
$this-inited or self::init( $arg1, $arg2 );
}
protected function init ( $arg1, $arg2 ) { print init in
super...BR; $this-inited = true; }
}
class superClass3 {
use templateInitializer;
}
class subClass3a extends superClass3 {
protected function init ( $arg1, $arg2 ) { print init in
sub...BR; }
}
class subClass3b extends superClass3 {}
class subSubClass3a1 extends subClass3a {
protected function init ( $arg1, $arg2 ) { print init in
sub-sub...BR; }
}
new superClass3 ( null, null ); // runs root init
new subClass3a ( null, null ); // runs child init, then root
new subClass3b ( null, null ); // runs root init
new subSubClass3a1 (null, null); // runs grandchild, then root
You can extend this model to preInit() and postInit() methods, giving
even more flexibility. And in none of these cases does the subclass
need to remember to do anything.
This thread arose in response to what is undeniably a bad API
authoring practice (first allowing full ctor override and later
breaking BC without fanfare). Why are we letting the authors of
Richard's library off the hook and putting it on ourselves to develop
hacks? They obviously screwed up. What next? Do we let API consumers
override a `final` that they don't like? Just use the right pattern in
the first place. IMO.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
