[PHP-DEV] Autoload Functions RFC in 5.5?
There is this wonderful RFC sitting around: https://wiki.php.net/rfc/autofunc Is there any chance that we can integrate this in 5.5 and somebody is willing to write this patch? The only topic missing from the RFC is how the fallback to global namespace works, if the autoloader is called before or after the fallback. greetings, Benjamin
[PHP-DEV] [RFC] Implement a LoggerInterface to PHP
Hello, After a talk on the Symfony framework here: https://github.com/symfony/symfony/issues/5911 Long story short, the point that @Seldaek suggestion to have a common interface for loggers actually makes sense and the best way to have it would be to have PHP include it by default. I'm not sure exactly what amount of work this implies, nor my C skills are existent, but with PHP having such an interface available it would help standardize things in the PHP world. Also, I'm not sure if this could be backported into existing PHP 5.3 or PHP 5.4 versions but this would make sense to consider it for PHP 5.5. What do you guys think? Could this be considered to be included in PHP? Thank you for your time. Best regards, Florin Florin Patan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implement a LoggerInterface to PHP
Hi, 2012/11/8 Florin Razvan Patan : > Hello, > > > After a talk on the Symfony framework here: > https://github.com/symfony/symfony/issues/5911 > Long story short, the point that @Seldaek suggestion to have a common > interface for loggers > actually makes sense and the best way to have it would be to have PHP > include it by default. > > I'm not sure exactly what amount of work this implies, nor my C skills > are existent, but with > PHP having such an interface available it would help standardize > things in the PHP world. > > Also, I'm not sure if this could be backported into existing PHP 5.3 > or PHP 5.4 versions > but this would make sense to consider it for PHP 5.5. > > What do you guys think? Could this be considered to be included in PHP? What's the benefit of having this made inside PHP itself? It's perfectly possible to share a common interface across projects even if not native to PHP. It's quite easy to create a PECL extension for that, that would suites your need regardless of PHP version, but again, I don't really see the benefit of doing that in C, at the core of PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implement a LoggerInterface to PHP
Florin, On Thu, Nov 8, 2012 at 6:42 AM, Florin Razvan Patan wrote: > Hello, > > > After a talk on the Symfony framework here: > https://github.com/symfony/symfony/issues/5911 > Long story short, the point that @Seldaek suggestion to have a common > interface for loggers > actually makes sense and the best way to have it would be to have PHP > include it by default. > > I'm not sure exactly what amount of work this implies, nor my C skills > are existent, but with > PHP having such an interface available it would help standardize > things in the PHP world. > > Also, I'm not sure if this could be backported into existing PHP 5.3 > or PHP 5.4 versions > but this would make sense to consider it for PHP 5.5. > > What do you guys think? Could this be considered to be included in PHP? > > Thank you for your time. > > > > > Best regards, > Florin > Pedantically speaking, isn't this the exact goal of the FIG/PSR group? That they define these common parts? Is there an advantage to having it in C (performance, etc)? If so, there may be something to discuss. But if it's just to enforce a common paradigm, I'd say leave that to the community to do. They are in a better position and can change their mind if they need to. Something that core is reasonably positioned to not do... Anthony
Re: [PHP-DEV] [RFC] Implement a LoggerInterface to PHP
2012/11/8 Anthony Ferrara > Florin, > > On Thu, Nov 8, 2012 at 6:42 AM, Florin Razvan Patan > wrote: > > > Hello, > > > > > > After a talk on the Symfony framework here: > > https://github.com/symfony/symfony/issues/5911 > > Long story short, the point that @Seldaek suggestion to have a common > > interface for loggers > > actually makes sense and the best way to have it would be to have PHP > > include it by default. > > > > I'm not sure exactly what amount of work this implies, nor my C skills > > are existent, but with > > PHP having such an interface available it would help standardize > > things in the PHP world. > > > > Also, I'm not sure if this could be backported into existing PHP 5.3 > > or PHP 5.4 versions > > but this would make sense to consider it for PHP 5.5. > > > > What do you guys think? Could this be considered to be included in PHP? > > > > Thank you for your time. > > > > > > > > > > Best regards, > > Florin > > > > Pedantically speaking, isn't this the exact goal of the FIG/PSR group? That > they define these common parts? > There are already discussing this (to be honest: For months now). Some are mentioned at the pull requests at https://github.com/php-fig/fig-standards/pulls > > Is there an advantage to having it in C (performance, etc)? If so, there > may be something to discuss. But if it's just to enforce a common paradigm, > I'd say leave that to the community to do. They are in a better position > and can change their mind if they need to. Something that core is > reasonably positioned to not do... > > Anthony > -- github.com/KingCrunch
[PHP-DEV] Small LICENSE question.
Hi, Most of PHP sources under PHP License are subject to version 3.01 Except enchant, fileinfo and pdo_obbc which are subject to version 3.0 Is it ok ? Thanks, Remi $ grep -lr 3_0.txt php-5.4.8 ./pear/install-pear-nozlib.phar ./ext/enchant/php_enchant.h ./ext/enchant/enchant.c ./ext/fileinfo/fileinfo.c ./ext/fileinfo/php_fileinfo.h ./ext/pdo_odbc/odbc_stmt.c ./ext/pdo_odbc/php_pdo_odbc_int.h ./ext/pdo_odbc/pdo_odbc.c ./ext/pdo_odbc/odbc_driver.c ./ext/pdo_odbc/php_pdo_odbc.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small LICENSE question.
for all mines, go ahead :) On Thu, Nov 8, 2012 at 3:14 PM, Remi Collet wrote: > Hi, > > Most of PHP sources under PHP License are subject to version 3.01 > > Except enchant, fileinfo and pdo_obbc which are subject to version 3.0 > > Is it ok ? > > Thanks, > Remi > > > $ grep -lr 3_0.txt php-5.4.8 > ./pear/install-pear-nozlib.phar > ./ext/enchant/php_enchant.h > ./ext/enchant/enchant.c > ./ext/fileinfo/fileinfo.c > ./ext/fileinfo/php_fileinfo.h > ./ext/pdo_odbc/odbc_stmt.c > ./ext/pdo_odbc/php_pdo_odbc_int.h > ./ext/pdo_odbc/pdo_odbc.c > ./ext/pdo_odbc/odbc_driver.c > ./ext/pdo_odbc/php_pdo_odbc.h > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implement a LoggerInterface to PHP
Sebastian, There are already discussing this (to be honest: For months now). > > Some are mentioned at the pull requests at > https://github.com/php-fig/fig-standards/pulls So then there's really no reason to be discussing it for core, is there?
Re: [PHP-DEV] Incomprehension with preg_match and utf8
Le 06/11/2012 11:17, Pierre Joye a écrit : >> php 5.2.10 (Rémi's RPM) - (PCRE 6.6 06-Feb-2006) : preg_match === 0 > I would try using the bundled PCRE instead. As far as I remember, > almost all distro uses the system PCRE and not always build with UTF-8 All my build use bundled pcre library when system one is < 8.10 for months... Output of 5.2.10 seems like provocation... ;) Remi P.S. Remi, not Rémi ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Object comparison
From: http://php.net/manual/en/language.operators.comparison.php
An object compared to anything which is not a bool, null, or object
should result in the object appearing to be greater than the other
operand. For example:
$a = new stdClass();
$b = new stdClass();
var_dump(null < $a);
var_dump(false < $a);
var_dump(true == $a);
var_dump($a == $b);
var_dump(0 < $a);
var_dump(1 < $a); // false
var_dump(2 < $a); // false
var_dump("foo" < $a);
var_dump("2" < $a);
var_dump(tmpfile() < $a);
Based on docs, I expect all nine of these to yield true, however in
practice, the two marked "false" come out as false because the RHS
object is converted to an integer (1), contrary to the docs.
Doc bug? Or code bug? I'm inclined to call it a code bug, but wanted
others' thoughts.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object comparison
Hi! > Doc bug? Or code bug? I'm inclined to call it a code bug, but wanted > others' thoughts. I would say comparing object to a number makes little sense, so no reason to define any specific result there. It may be true, false or bologna sandwich. The docs say what happens when the first parameter is object, but say nothing what happens if the second one is object. This is for reason - if you compare object to array, they can't both be greater, something has to take priority. The docs say first arg takes priority. So by docs, comparison of (number, object) has no defined value, while comparison of (object, number) has. -- 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] [RFC] Implement a LoggerInterface to PHP
On 11/08/2012 08:42 AM, Anthony Ferrara wrote: Sebastian, There are already discussing this (to be honest: For months now). Some are mentioned at the pull requests at https://github.com/php-fig/fig-standards/pulls So then there's really no reason to be discussing it for core, is there? There is not. This is a task for the FIG group, not Internals. --Larry Garfield, Drupal rep to the FIG group -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.18RC1 and 5.4.8RC1 Released for Testing!
Hi! We've released PHP 5.3.19RC1 and 5.4.9RC1 which can be found here: 5.3.19RC1: http://downloads.php.net/johannes/php-5.3.19RC1.tar.bz2 http://downloads.php.net/johannes/php-5.3.19RC1.tar.gz 5.4.9RC1: http://downloads.php.net/stas/php-5.4.9RC1.tar.bz2 http://downloads.php.net/stas/php-5.4.9RC1.tar.gz Windows binaries for both as always are at: http://windows.php.net/qa/ These are release candidates for regular bugfix releases, the full list of issues fixed can be found in the NEWS files. Please test and report if anything is broken. If no critical issues are found in these RCs, the final versions will be released in two weeks. Regards, Stas Malyshev Johannes Schlüter PHP 5.4 Release Master PHP 5.3 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object comparison
On Thu, Nov 8, 2012 at 7:07 PM, Sara Golemon wrote:
> From: http://php.net/manual/en/language.operators.comparison.php
>
> An object compared to anything which is not a bool, null, or object
> should result in the object appearing to be greater than the other
> operand. For example:
>
> $a = new stdClass();
> $b = new stdClass();
>
> var_dump(null < $a);
> var_dump(false < $a);
> var_dump(true == $a);
> var_dump($a == $b);
> var_dump(0 < $a);
> var_dump(1 < $a); // false
> var_dump(2 < $a); // false
> var_dump("foo" < $a);
> var_dump("2" < $a);
> var_dump(tmpfile() < $a);
>
> Based on docs, I expect all nine of these to yield true, however in
> practice, the two marked "false" come out as false because the RHS
> object is converted to an integer (1), contrary to the docs.
>
> Doc bug? Or code bug? I'm inclined to call it a code bug, but wanted
> others' thoughts.
>
Hi Sara,
I believe the documentation is failing us here.
>From what I see the docs are pretty lacking in what should be expected
in terms of object comparison.
For example, the page at http://php.net/types.comparisons doesn't even
include objects in the comparison table.
Of course by looking at the "Comparison with Various Types" table at
http://php.net/language.operators.comparison one gets the impression
that the "Operand 1" and "Operand 2" columns are to signify LVALUE and
RVALUE operands, respectively. Obviously this isn't the case and the
documentation just fails us here.
var_dump(new stdclass < 1, newstdcalss > 1, 1 < new stdclass, 1 > new
stdclass); // false, false, false, false
Clearly there are cases when the object can be neither less-than nor
greater-than an operand in a comparison.
The statement "object is always greater" in that table is misleading
and doesn't tell us the whole truth.
For example,
class foo { public function __toString() { return ''; } }
var_dump(new foo < '', new foo > '', '' < new foo, '' > new foo); //
false, false, false, false
Obviously there are more complex cases where the object may not pan
out to be greater than a non-object type that the documentation fails
to address.
> -Sara
>
> --
> 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
