[PHP-DEV] Function return values in PHP5.3
Hi Lukas, Johannes Please could I ask for a PHP5.3 release manager's point of view on this? I raised this ext/imap bug yesterday http://bugs.php.net/bug.php?id=46902 after a discussion with Ilia because I noticed that all of the function return values which result from a failure of parameter parsing had changed from 'false' in PHP5.2 to NULL in PHP5.3. So, questions: 1) Is the accepted practice that functions will return NULL when zend_parse_parameters() fails in PHP5.3? 2) Is it acceptable to change the behaviour of functions between 5.2 and 5.3? 3) Does this apply to *all* PHP functions? 4) Assuming that the answer (3) is no, is there any documentation about which functions have changed? (If not would you like some?) Zoë -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Function return values in PHP5.3
Hi, On Fri, 2008-12-19 at 09:18 +, zoe wrote: Hi Lukas, Johannes Please could I ask for a PHP5.3 release manager's point of view on this? I raised this ext/imap bug yesterday http://bugs.php.net/bug.php?id=46902 after a discussion with Ilia because I noticed that all of the function return values which result from a failure of parameter parsing had changed from 'false' in PHP5.2 to NULL in PHP5.3. 1) Is the accepted practice that functions will return NULL when zend_parse_parameters() fails in PHP5.3? If the parameters given to a function are not what it expects, such as passing an array where a string is expected, the return value of the function is undefined. In this case it will likely return NULL but this is just a convention, and cannot be relied upon. http://www.php.net/manual/en/functions.internal.php 2) Is it acceptable to change the behaviour of functions between 5.2 and 5.3? In most cases a wrong parameter parsing should happen during development not in production so there shouldn't be a too big impact for productive systems. But I know people doing strange things. Since null == false in most situations the change from false to NULL shouldn't be noticed. Changing the return value might even help to make PHP more consistent and follow the docs (as above). But ... 3) Does this apply to *all* PHP functions? ... there might be exceptions. Some functions, like strpos(), might return 0 as a successful value and false for errors. So people check using strpos !== false which won't catch all errors when returning NULL. The interesting part there is that strpos() follows the return NULL on param parsing error-rule in 5.2 already. So in that case changing the return value the other way round might make the code more robust ;-) The same goes, btw. for fgets - string(1) 0 might be a valid return value, so people might check using === false for a general error, but 5.2 returns NULL for wrong parameter parsing. 4) Assuming that the answer (3) is no, is there any documentation about which functions have changed? (If not would you like some?) From top of my head I don't see another function where this is relevant. And in my opinion somebody who depends on wrong parameter parsing does things wrong. If then checking for false using === the user also depends on not strictly defined behavior (see quote from above again) But I'd like others to think about edge cases like strpos(), fgets(), ... where a value evaluating to false is a successful return value or other related edge cases .. (is there any place where one uses wrong parameters on purpose?) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Just a random thought I have from reading over that:
Would it not be more 'natural' to change 'function' to indicate a
method with a variant return type, and allow e.g.
'int somefunc()' instead of 'function (int) somefunc()' to indicate an
int return?
It would be a bit more in fitting with traditional languages, and
definitely less typing.. it may require some parser modification,
though..?
(I'd also like to throw my +1 in for scalar type hints, and optional
type coercion for return values - this is something I have run into
annoyances with and blogged about in the past)
Thanks,
Robin Burchell
On Fri, Dec 19, 2008 at 2:23 AM, Kalle Sommer Nielsen ka...@php.net wrote:
2008/12/18 Nathan Rixham nrix...@gmail.com:
Nathan Rixham wrote:
and strongly typed returns.. nearly forgot
public static function parseByte( Number $var ):bool {
or
public static function bool parseByte( Number $var ) {
or such like
Theres already an RFC for this:
http://wiki.php.net/rfc/typehint
--
Kalle Sommer Nielsen
--
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] Q on Primitives
Robin Burchell wrote:
Just a random thought I have from reading over that:
Would it not be more 'natural' to change 'function' to indicate a
method with a variant return type, and allow e.g.
'int somefunc()' instead of 'function (int) somefunc()' to indicate an
int return?
it would break all php code existing so far; the only real way to
implement return value types would be as such
public static function somefunc():int {
this would allow the return type to be optional and leave all existing
code functional; likewise it could be implemented for any style of
php'ing, thus:
#php4 style class method or normal procedural function
function dosumit():int {
type hints are all ready there so adding primitives /should/ be possible
without any bc issues
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Hmm. How would it break it?
By leaving 'function' to mean variant, it's only adding new
functionality by overriding types to replace 'function', which should
have no issue with older code, surely?
To clarify:
current method declaration:
function foo()
public static function foo()
public function foo()
.. and so on
new method declaration could stay the same, if the author didn't care
about return type, or:
int foo()
public int foo()
.. etc.
The only possible issue I can see is where e.g. there is a class named
'static', which, IIRC is already impossible.
If I'm missing something, please let me know :)
On Fri, Dec 19, 2008 at 2:31 PM, Nathan Rixham nrix...@gmail.com wrote:
Robin Burchell wrote:
Just a random thought I have from reading over that:
Would it not be more 'natural' to change 'function' to indicate a
method with a variant return type, and allow e.g.
'int somefunc()' instead of 'function (int) somefunc()' to indicate an
int return?
it would break all php code existing so far; the only real way to implement
return value types would be as such
public static function somefunc():int {
this would allow the return type to be optional and leave all existing code
functional; likewise it could be implemented for any style of php'ing, thus:
#php4 style class method or normal procedural function
function dosumit():int {
type hints are all ready there so adding primitives /should/ be possible
without any bc issues
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
On Fri, Dec 19, 2008 at 3:31 PM, Nathan Rixham nrix...@gmail.com wrote: type hints are all ready there so adding primitives /should/ be possible without any bc issues PHP is loosely typed. Adding typehints to primitives would change this. The only reason that it is working with object types, is because you can't automatically coerce object types anyway. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
On Fri, Dec 19, 2008 at 2:40 PM, troels knak-nielsen troel...@gmail.com wrote: PHP is loosely typed. Adding typehints to primitives would change this. The only reason that it is working with object types, is because you can't automatically coerce object types anyway. -- troels I'm not sure what you are getting at here, really: the suggested functionality is optional, and a new addition mean that it indeed will not have an effect on backwards compatibility. What was the purpose of your mail? I cannot furthermore see why providing the choice for people to strong-type when it suits their purposes as well as allowing weak typing when useful is such a bad thing. Indeed, I'd quite love for this mixture :) I agree that typing *can* be accomplished in other ways, e.g. instanceof and various other hacks, but they are then not enforcing it in a uniform and controlled manner as type hinting does, plus they are less elegant than providing it as an optional first class language feature. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Robin Burchell wrote: Hmm. How would it break it? By leaving 'function' to mean variant, it's only adding new functionality by overriding types to replace 'function', which should have no issue with older code, surely? To clarify: current method declaration: function foo() public static function foo() public function foo() because all of those current declarations would no longer work on the new version of php which implemented such change..? and I'm assuming it would be a much bigger change to the php internals than adding in an optional type after the method params..? I do like the type method() syntax though, but don't think it's a php thing..? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Ugh. Apparantly I forgot to CC the list on those last two mails.. Sorry. Pasted so others stay in on the conversation: On Fri, Dec 19, 2008 at 3:18 PM, troels knak-nielsen troel...@gmail.com wrote: snip That's an interesting mail, expresses a viewpoint I hadn't considered, so, thanks for that. However: If PHP provides such a set in stone opinion on how things should be done, then why does it support, for example, provide class vs functional programming paradigms - both to a first degree level? (the mysqli extension is a very good example of what I mean here). As I have seen it, PHP is one of the best of all tools: it provides the features that many different programmers wish to use, and allows them to use it. It doesn't restrict itself to any single spectrum of programming, and I think that robustness is one reason it has flourished, and continues to do so well into the future. I see this as just another logical extension of that philosophy: you see this as being not the PHP way, whilst I see it as the polar opposite: enabling programmers to do things as they wish, which I have always thought was very much the PHP way :) On Fri, Dec 19, 2008 at 3:09 PM, Nathan Rixham nrix...@gmail.com wrote: because all of those current declarations would no longer work on the new version of php which implemented such change..? and I'm assuming it would be a much bigger change to the php internals than adding in an optional type after the method params..? They would continue to work, because (you seem to be missing this point of what I am suggesting) - 'function' would just mean a return of a variant type (i.e. the current behaviour of not caring what it is, and not touching it in any way Whether or not it is a large change I am not qualified to suggest; I haven't yet done too extensive a digging into the internals. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
On 12/19/2008 17:39, Robin Burchell wrote: Ugh. Apparantly I forgot to CC the list on those last two mails.. Sorry. Pasted so others stay in on the conversation: On Fri, Dec 19, 2008 at 3:18 PM, troels knak-nielsentroel...@gmail.com wrote: snip That's an interesting mail, expresses a viewpoint I hadn't considered, so, thanks for that. However: If PHP provides such a set in stone opinion on how things should be done, then why does it support, for example, provide class vs functional programming paradigms - both to a first degree level? (the mysqli extension is a very good example of what I mean here). As I have seen it, PHP is one of the best of all tools: it provides the features that many different programmers wish to use, and allows them to use it. It doesn't restrict itself to any single spectrum of programming, and I think that robustness is one reason it has flourished, and continues to do so well into the future. I see this as just another logical extension of that philosophy: you see this as being not the PHP way, whilst I see it as the polar opposite: enabling programmers to do things as they wish, which I have always thought was very much the PHP way :) On Fri, Dec 19, 2008 at 3:09 PM, Nathan Rixhamnrix...@gmail.com wrote: because all of those current declarations would no longer work on the new version of php which implemented such change..? and I'm assuming it would be a much bigger change to the php internals than adding in an optional type after the method params..? They would continue to work, because (you seem to be missing this point of what I am suggesting) - 'function' would just mean a return of a variant type (i.e. the current behaviour of not caring what it is, and not touching it in any way Whether or not it is a large change I am not qualified to suggest; I haven't yet done too extensive a digging into the internals. Actually functional programming [1] is a different beast than what you are referring to, which is called procedural programming [2]. In that regard, a database interface like mysqli is hardly functional. Sorry if I've hijacked the discussion somehow. [1] http://en.wikipedia.org/wiki/Functional_programming [2] http://en.wikipedia.org/wiki/Procedural_programming -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 2008 is 1s longer than normal.
Richard Quadling wrote: Hi. With 2008 having a leap-second, does PHP handle this? In looking at http://en.wikipedia.org/wiki/Leap_second, there have been quite a few leap seconds - 34 since Jan 1st 1972. So, if PHP isn't making any changes does this mean PHP time is 34 seconds behind UTC? Unix time conventionally does not include leap seconds. This allows ordinary applications to convert seconds-since-epoch to calendar dates without any knowledge of leap seconds. Ntpd is tasked with changing the system clock to account for this, ultimately in response to a leap second change propagated from the stratum 1 time servers. http://www.eecis.udel.edu/~mills/leap.html -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] config files and PHP_CONFIG_FILE_SCAN_DIR
For some time, PHP has had a build option
./configure --with-config-file-scan-dir=/etc/php5/conf.d/
that allows distribution maintainers to manage system-wide PHP
configuration by adding/removing individual files with configuration
fragments to this directory, for example when installing a package with
a compiled PHP an extension.
This is an improvement over the previous situation where php.ini had to
be edited by package install/remove scripts.
On Debian and Ubuntu systems (and maybe others), each SAFI ie. apache2
module, cli, or cgi is compiled with a different location of php.ini and
config-file-scan-dir. (which is a bit redundant, with the option of
naming it php-cli.ini, php-apache2.ini etc.)
Also, the config-file-scan-dir is set
to /etc/php5/apache2/conf.d, /etc/php5/cli/conf.d, which are then
symlinked to /etc/php5/conf.d, (also a bit redundant)
So it seems, it is easy to have system-wide settings in multiple
separate files, which is good for packagers, but per-SAFI configuration
must still be in *one* php.ini choosen from several locations in the
ini-search-path.
I wonder if the config-file-scan-dir could be a path with multiple
directories to search, then each SAFI could be compiled with a common
and a per-SAFI directory to scan.
It could be a loop around this part of main/php_ini.c around line 512:
/* If the config_file_scan_dir is set at compile-time, go and
scan this directory and
* parse any .ini files found in this directory. */
if (!sapi_module.php_ini_ignore
strlen(PHP_CONFIG_FILE_SCAN_DIR)) {
The config-file-cscan-path could then
be /etc/php5/conf.d:/etc/php5/apache2.d
or /etc/php5/conf.d:/etc/php5/cli.d
Depending how much change is wanted/tolerated, this could get rid of the
other special cases that search for ini-files in a path, which searches
for php-$SAFI.ini, then php.ini, etc. since they could be put in the
config-file-scan-path.
--
Jeremy Jackson
Coplanar Networks
(519)489-4903
http://www.coplanar.net
j...@coplanar.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Request for testers: svn.php.net
Hello all (and sorry for the cross-posting, please keep all replies to svn-migration@) After weeks of hard work from Gwynne, svn.php.net is now in a very good shape and ready for extensive testing. There is no automatic synchronization between CVS and SVN, and there will not be one. You are free to commit as you want to SVN, trying to break SVN in whatever ways you can think of. All changes to SVN will be overwritten when the switch is flipped and we move to SVN and abandon CVS. The only thing that is kept up-to-date is the karma (CVSROOT/avail), both the global and the PEAR specific one, so feel free to test and make sure you can commit to things you should be able to, and that you cannot commit to things you shouldn't. Extensive testing is obviously required before we can make the switch, so feel free to go nuts! There is no SVN category on bugs.php.net, and I do not anticipate that we need one. Please just send all bugs you may encounter to svn-migrat...@lists.php.net To gain access to svn.php.net you have to validate your CVS account. This is automatically done by logging into master (https://master.php.net/login.php) or the wiki (http://wiki.php.net). Your access credentials will be synchronized within 15minutes. Note: No, it is not enough to login to bugsweb (or cvs for that matter) as it uses local copy of the credentials database so we cannot automatically do the nescecery account upgrades. There is an anonymous cvsread account for SVN, called svnread with the password svnread. Gotchas: - The directory structure has changed slightly. The root directories represent will probably be its own repository in the future. Poke around on http://svn.php.net/ to see the specifics. - SVN 1.5.1 does not work (for php-src at least). You will have to upgrade to 1.5.2 (or later) - karma is manually updated - Commit emails have their subject prefixed with [TESTING] (note: emails *are* sent to the correct mailinglists) - You cannot checkout the entire repository on case-insensitive filesystem - CVS commits are *not* synced to SVN - SVN commits are *not* synced to CVS There is no official flipping-the-switch date, but to have some date in mind I think February 1st is entirely plausible date. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Undefined constants producing E_NOTICE
Hello everyone, Currently when an undefined constant is called, E_NOTICE is produced and the name of the constant is assumed to be a string. In my opinion this behaviour is strange and problematic for most developers. Maybe it would be good if invoking undefined constants will start to produce at least E_WARNING? For the moment some unexpected behaviour caused by use of undefined constant may be hard to fix with low error reporting level. Moreover, treating an undefined constant as a string does not make sense. I know that PHP is intended to be a flexible language, but for me it's a bit thick. Regards, faw -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
