Re: [PHP-DEV] PHP: PHP 6 Release date
hi, PHP 6 branch has been killed. Trunk is now the development branch and there is yet no date for the next major release (be 5.4 or 6). Cheers, On Mon, Jun 28, 2010 at 9:35 AM, Alexander Schunk asch...@gmail.com wrote: Hello, i have a question concerning php 6. When will php 6 be released and is there a ressource where i can find information about new features. There are rumors about utf implementation and new string classes. Will php 6 be released within this year or later. yours sincerly Alexander Schunk -- 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] PHP: PHP 6 Release date
and the AFAIK current(PHP6) unicode implementation isn't going to be included in the next major release (be 5.4 or 6). Tyrael On Mon, Jun 28, 2010 at 9:46 AM, Pierre Joye pierre@gmail.com wrote: hi, PHP 6 branch has been killed. Trunk is now the development branch and there is yet no date for the next major release (be 5.4 or 6). Cheers, On Mon, Jun 28, 2010 at 9:35 AM, Alexander Schunk asch...@gmail.com wrote: Hello, i have a question concerning php 6. When will php 6 be released and is there a ressource where i can find information about new features. There are rumors about utf implementation and new string classes. Will php 6 be released within this year or later. yours sincerly Alexander Schunk -- 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
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branches/PHP_5_3/Zend/zend_compile.c
Hi,
On Sat, 2010-06-26 at 22:05 +, Felipe Pena wrote:
felipe Sat, 26 Jun 2010 22:05:13 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=300770
Log:
- Fixed bug #51421 (Abstract __construct constructor argument list not
enforced)
Bug: http://bugs.php.net/51421 (Closed) Abstract __construct constructor
argument list not enforced
Won't this break compatibility?
I'd say the change is logically correct but not sure we should break BC
there during RC.
johannes
Changed paths:
A php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
U php/php-src/branches/PHP_5_2/Zend/zend_compile.c
A php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
U php/php-src/branches/PHP_5_3/Zend/zend_compile.c
A php/php-src/trunk/Zend/tests/bug51421.phpt
U php/php-src/trunk/Zend/zend_compile.c
Added: php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
===
--- php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
(rev 0)
+++ php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt 2010-06-26
22:05:13 UTC (rev 300770)
@@ -0,0 +1,18 @@
+--TEST--
+Bug #51421 (Abstract __construct constructor argument list not enforced)
+--FILE--
+?php
+
+class ExampleClass {}
+
+abstract class TestInterface {
+ abstract public function __construct(ExampleClass $var);
+}
+
+class Test extends TestInterface {
+ public function __construct() {}
+}
+
+?
+--EXPECTF--
+Fatal error: Declaration of Test::__construct() must be compatible with that
of TestInterface::__construct() in %s on line %d
Property changes on: php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
___
Added: svn:keywords
+ Id Rev Revision
Added: svn:eol-style
+ native
Modified: php/php-src/branches/PHP_5_2/Zend/zend_compile.c
===
--- php/php-src/branches/PHP_5_2/Zend/zend_compile.c 2010-06-26 21:29:56 UTC
(rev 300769)
+++ php/php-src/branches/PHP_5_2/Zend/zend_compile.c 2010-06-26 22:05:13 UTC
(rev 300770)
@@ -2009,13 +2009,20 @@
{
zend_uint i;
- /* If it's a user function then arg_info == NULL means we don't have
any parameters but we still need to do the arg number checks. We are only
willing to ignore this for internal functions because extensions don't always
define arg_info. */
+ /* If it's a user function then arg_info == NULL means we don't have
any parameters but
+ * we still need to do the arg number checks. We are only willing to
ignore this for internal
+ * functions because extensions don't always define arg_info.
+ */
if (!proto || (!proto-common.arg_info proto-common.type !=
ZEND_USER_FUNCTION)) {
return 1;
}
- /* Checks for constructors only if they are declared in an interface */
- if ((fe-common.fn_flags ZEND_ACC_CTOR)
!(proto-common.scope-ce_flags ZEND_ACC_INTERFACE)) {
+ /* Checks for constructors only if they are declared in an interface,
+ * or explicitly marked as abstract
+ */
+ if ((fe-common.fn_flags ZEND_ACC_CTOR)
+ ((proto-common.scope-ce_flags ZEND_ACC_INTERFACE) == 0
+ (proto-common.fn_flags ZEND_ACC_ABSTRACT) == 0)) {
return 1;
}
Added: php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
===
--- php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
(rev 0)
+++ php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt 2010-06-26
22:05:13 UTC (rev 300770)
@@ -0,0 +1,18 @@
+--TEST--
+Bug #51421 (Abstract __construct constructor argument list not enforced)
+--FILE--
+?php
+
+class ExampleClass {}
+
+abstract class TestInterface {
+ abstract public function __construct(ExampleClass $var);
+}
+
+class Test extends TestInterface {
+ public function __construct() {}
+}
+
+?
+--EXPECTF--
+Fatal error: Declaration of Test::__construct() must be compatible with that
of TestInterface::__construct() in %s on line %d
Property changes on: php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
___
Added: svn:keywords
+ Id Rev Revision
Added: svn:eol-style
+ native
Modified: php/php-src/branches/PHP_5_3/Zend/zend_compile.c
===
--- php/php-src/branches/PHP_5_3/Zend/zend_compile.c 2010-06-26 21:29:56 UTC
(rev 300769)
+++ php/php-src/branches/PHP_5_3/Zend/zend_compile.c 2010-06-26 22:05:13 UTC
(rev 300770)
@@ -2532,13 +2532,20 @@
{
zend_uint i;
- /* If it's a user function then arg_info == NULL
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branches/PHP_5_3/Zend/zend_com
Hi,
2010/6/28 Johannes Schlüter johan...@schlueters.de
Hi,
On Sat, 2010-06-26 at 22:05 +, Felipe Pena wrote:
felipe Sat, 26 Jun 2010 22:05:13 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=300770
Log:
- Fixed bug #51421 (Abstract __construct constructor argument list not
enforced)
Bug: http://bugs.php.net/51421 (Closed) Abstract __construct constructor
argument list not enforced
Won't this break compatibility?
I'd say the change is logically correct but not sure we should break BC
there during RC.
At the risk of starting some political debate, I believe that the current
state of prototype checks make close to no sense in PHP, for 4 reasons:
1) arguments can be gathered dynamically in the function, using
func_get_args. For that reason, PHP gracefully allow a call with too many
arguments.
2) a child method should be allowed to define type hints in a contra-variant
manner (currently, it's invariant)
3) a child method should be allowed to return a ref even if the parent
method is not defined to do so. (returning a ref is an additional
constraint, and following co-variance of return values, it should be
allowed). The basic example of this annoyance is: abstract class A
implements ArrayAcces { public function __offsetGet($name) { ... } }
4) all in all: it shouldn't throw a fatal error, those are not critical
situations for the engine.
I'd like to propose to relax such checks, by either allowing more (e.g. 1, 2
and 3) which can be painful and complicated, or simply removing those
checks.
Best,
johannes
Changed paths:
A php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
U php/php-src/branches/PHP_5_2/Zend/zend_compile.c
A php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
U php/php-src/branches/PHP_5_3/Zend/zend_compile.c
A php/php-src/trunk/Zend/tests/bug51421.phpt
U php/php-src/trunk/Zend/zend_compile.c
Added: php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
===
--- php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
(rev 0)
+++ php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt 2010-06-26
22:05:13 UTC (rev 300770)
@@ -0,0 +1,18 @@
+--TEST--
+Bug #51421 (Abstract __construct constructor argument list not enforced)
+--FILE--
+?php
+
+class ExampleClass {}
+
+abstract class TestInterface {
+ abstract public function __construct(ExampleClass $var);
+}
+
+class Test extends TestInterface {
+ public function __construct() {}
+}
+
+?
+--EXPECTF--
+Fatal error: Declaration of Test::__construct() must be compatible with
that of TestInterface::__construct() in %s on line %d
Property changes on:
php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
___
Added: svn:keywords
+ Id Rev Revision
Added: svn:eol-style
+ native
Modified: php/php-src/branches/PHP_5_2/Zend/zend_compile.c
===
--- php/php-src/branches/PHP_5_2/Zend/zend_compile.c 2010-06-26 21:29:56
UTC (rev 300769)
+++ php/php-src/branches/PHP_5_2/Zend/zend_compile.c 2010-06-26 22:05:13
UTC (rev 300770)
@@ -2009,13 +2009,20 @@
{
zend_uint i;
- /* If it's a user function then arg_info == NULL means we don't
have any parameters but we still need to do the arg number checks. We are
only willing to ignore this for internal functions because extensions don't
always define arg_info. */
+ /* If it's a user function then arg_info == NULL means we don't
have any parameters but
+ * we still need to do the arg number checks. We are only willing
to ignore this for internal
+ * functions because extensions don't always define arg_info.
+ */
if (!proto || (!proto-common.arg_info proto-common.type !=
ZEND_USER_FUNCTION)) {
return 1;
}
- /* Checks for constructors only if they are declared in an
interface */
- if ((fe-common.fn_flags ZEND_ACC_CTOR)
!(proto-common.scope-ce_flags ZEND_ACC_INTERFACE)) {
+ /* Checks for constructors only if they are declared in an
interface,
+ * or explicitly marked as abstract
+ */
+ if ((fe-common.fn_flags ZEND_ACC_CTOR)
+ ((proto-common.scope-ce_flags ZEND_ACC_INTERFACE) ==
0
+ (proto-common.fn_flags ZEND_ACC_ABSTRACT) ==
0)) {
return 1;
}
Added: php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
===
--- php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
(rev 0)
+++ php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt 2010-06-26
22:05:13 UTC (rev 300770)
@@ -0,0 +1,18 @@
+--TEST--
+Bug #51421
Re: [PHP-DEV] PDO_DBLIB Tests
Go ahead, if you have karma, more tests are always welcome. On Sun, Jun 27, 2010 at 8:17 PM, Stanley Sufficool ssuffic...@gmail.com wrote: I have several tests to submit for ext/pdo_dblib. I have karma to submit patches for ext/pdo_dblib, do I need a blessing to submit ext/pdo_dblib/tests tests to trunk? -- 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
[PHP-DEV] SVN Account Request: johnyp
Maintaining my code for group of people working together on the same latest code. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: johnyp
What code? You only need a SVN account if you have something to contribute to the PHP runtime. - Scott On Jun 28, 2010, at 8:03 AM, johny pukhramba, wrote: Maintaining my code for group of people working together on the same latest code. -- 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
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branches/PHP_5_3/Zend/zend_compile
2010/6/28 Johannes Schlüter johan...@schlueters.de Hi, On Sat, 2010-06-26 at 22:05 +, Felipe Pena wrote: felipe Sat, 26 Jun 2010 22:05:13 + Revision: http://svn.php.net/viewvc?view=revisionrevision=300770 Log: - Fixed bug #51421 (Abstract __construct constructor argument list not enforced) Bug: http://bugs.php.net/51421 (Closed) Abstract __construct constructor argument list not enforced Won't this break compatibility? I'd say the change is logically correct but not sure we should break BC there during RC. Reverted. ;) -- Regards, Felipe Pena
[PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branch
Hi!
1) arguments can be gathered dynamically in the function, using
func_get_args. For that reason, PHP gracefully allow a call with too many
arguments.
Isn't it the case today?
Maybe also we can add some syntax like:
function foo($a, $b, ...) - where ... means I'll deal with those
arguments myself, ignore any compatibility checks so if the prototype
is foo($a,$b,$c) $a and $b would be checked but not $c and the function
is considered to have enough args.
2) a child method should be allowed to define type hints in a contra-variant
manner (currently, it's invariant)
This needs to be fixed.
3) a child method should be allowed to return a ref even if the parent
method is not defined to do so. (returning a ref is an additional
constraint, and following co-variance of return values, it should be
allowed). The basic example of this annoyance is: abstract class A
implements ArrayAcces { public function__offsetGet($name) { ... } }
This needs to be fixed too.
4) all in all: it shouldn't throw a fatal error, those are not critical
situations for the engine.
I'd say in general OO part of PHP seems to be much more strict and
Java-like than the rest. I'm not sure it's good. I'd demote all
situations where the engine has a way to proceed to at least warning level.
I'd like to propose to relax such checks, by either allowing more (e.g. 1, 2
and 3) which can be painful and complicated, or simply removing those
checks.
I think we shouldn't remove them - we should fix them. It doesn't seem
to be too hard, IMHO.
--
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
[PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branch
Hi,
On Mon, Jun 28, 2010 at 20:17, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
1) arguments can be gathered dynamically in the function, using
func_get_args. For that reason, PHP gracefully allow a call with too many
arguments.
Isn't it the case today?
It's the case at the time of the calls. But not when overriding a method:
class A { public function foo($a) { } }
class B extends A { public function foo() {} }
is considered invalid, but $obj-foo($arg); would be perfectly valid for
both objects.
Maybe also we can add some syntax like:
function foo($a, $b, ...) - where ... means I'll deal with those arguments
myself, ignore any compatibility checks so if the prototype is
foo($a,$b,$c) $a and $b would be checked but not $c and the function is
considered to have enough args.
I'd find that syntax pretty explicit and easy to understand, it wouldn't
break any BC.
2) a child method should be allowed to define type hints in a
contra-variant
manner (currently, it's invariant)
This needs to be fixed.
3) a child method should be allowed to return a ref even if the parent
method is not defined to do so. (returning a ref is an additional
constraint, and following co-variance of return values, it should be
allowed). The basic example of this annoyance is: abstract class A
implements ArrayAcces { public function__offsetGet($name) { ... } }
This needs to be fixed too.
4) all in all: it shouldn't throw a fatal error, those are not critical
situations for the engine.
I'd say in general OO part of PHP seems to be much more strict and
Java-like than the rest. I'm not sure it's good. I'd demote all situations
where the engine has a way to proceed to at least warning level.
I don't believe that any of those checks causes difficulty for the engine,
especially considering that internal classes can pretty much to what they
want anyway.
I'd like to propose to relax such checks, by either allowing more (e.g. 1,
2
and 3) which can be painful and complicated, or simply removing those
checks.
I think we shouldn't remove them - we should fix them. It doesn't seem to
be too hard, IMHO.
Enforcing contra-variance can become a tad bit tricky when it comes to:
1) argument vs no argument
2) argument with/without null as default value
3) by ref or not (with/without default values)
We should probably specify it formally in which case a prototype is
accepted, and then see what needs to be fixed.
Also, checking for subtyping in PHP is O(n) which is slow, but I don't
believe it's a concern big enough to change the way we implement
instanceof.
Best,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Etienne Kneuss
http://www.colder.ch
