Bug #60536 [Com]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1
ID: 60536
Comment by: g...@php.net
Reported by:scott...@php.net
Summary:Traits Segfault
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: ubuntu 11.11
PHP Version:5.4SVN-2011-12-15 (SVN)
Block user comment: N
Private report: N
New Comment:
Hi Laruence:
Your patch was also what I had thought of for the first moment, however, that
is
not actually fixing the bug.
The problem is another one. For some reason the property value does not get set
properly. At least that is my current understanding.
This leads to either some inconsistent ref count, or an inappropriately shared
zval. Haven't figured that out yet.
What you patch does is just changing the semantics of when properties are
composed into the class.
That is also something that happens to be broken (inconsistent with normal
inheritance).
I have updated tests that should describe the correct semantics for property
handling.
If you see where I do something stupid with the zvals, please let me know.
Thanks
Stefan
Previous Comments:
[2011-12-16 15:57:01] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60536.phpt
Revision: 1324051021
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.phpt&revision=1324051021
[2011-12-16 15:54:15] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60536.patch
Revision: 1324050855
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.patch&revision=1324050855
[2011-12-15 20:38:27] scott...@php.net
backtrace:
#0 0x000100289c71 in zend_mm_check_ptr (heap=0x10100, ptr=0x100c4f730,
silent=1, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:1380
#1 0x00010028c1ad in _zend_mm_free_int (heap=0x10100, p=0x100c4f730,
__zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2064
#2 0x00010028de9d in _efree (ptr=0x100c4f730, __zend_filename=0x1005476a8
"/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_vm_execute.h",
__zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2436
#3 0x0001003742c8 in i_zval_ptr_dtor [inlined] () at
/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_execute.h:88
#4 0x0001003742c8 in ZEND_RETURN_SPEC_VAR_HANDLER
(execute_data=0x1009802f8)
at zend_execute.h:10833
#5 0x00010032a882 in execute (op_array=0x1009bad50) at
zend_vm_execute.h:410
#6 0x0001002d733b in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:1272
#7 0x000100219973 in php_execute_script (primary_file=0x7fff5fbff170) at
main.c:2476
[2011-12-15 20:37:07] scott...@php.net
Description:
Following code crashes.
Test script:
---
x; }
}
class Z extends Y {
function z() { return ++$this->x; }
}
$a = new Z();
$a->x();
--
Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #60536 [PATCH]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1
ID: 60536
Patch added by: g...@php.net
Reported by:scott...@php.net
Summary:Traits Segfault
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: ubuntu 11.11
PHP Version:5.4SVN-2011-12-15 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: property005.phpt
Revision: 1324052348
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=property005.phpt&revision=1324052348
Previous Comments:
[2011-12-16 16:17:37] g...@php.net
Hi Laruence:
Your patch was also what I had thought of for the first moment, however, that
is
not actually fixing the bug.
The problem is another one. For some reason the property value does not get set
properly. At least that is my current understanding.
This leads to either some inconsistent ref count, or an inappropriately shared
zval. Haven't figured that out yet.
What you patch does is just changing the semantics of when properties are
composed into the class.
That is also something that happens to be broken (inconsistent with normal
inheritance).
I have updated tests that should describe the correct semantics for property
handling.
If you see where I do something stupid with the zvals, please let me know.
Thanks
Stefan
[2011-12-16 15:57:01] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60536.phpt
Revision: 1324051021
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.phpt&revision=1324051021
[2011-12-16 15:54:15] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60536.patch
Revision: 1324050855
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.patch&revision=1324050855
[2011-12-15 20:38:27] scott...@php.net
backtrace:
#0 0x000100289c71 in zend_mm_check_ptr (heap=0x10100, ptr=0x100c4f730,
silent=1, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:1380
#1 0x00010028c1ad in _zend_mm_free_int (heap=0x10100, p=0x100c4f730,
__zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2064
#2 0x00010028de9d in _efree (ptr=0x100c4f730, __zend_filename=0x1005476a8
"/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_vm_execute.h",
__zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2436
#3 0x0001003742c8 in i_zval_ptr_dtor [inlined] () at
/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_execute.h:88
#4 0x0001003742c8 in ZEND_RETURN_SPEC_VAR_HANDLER
(execute_data=0x1009802f8)
at zend_execute.h:10833
#5 0x00010032a882 in execute (op_array=0x1009bad50) at
zend_vm_execute.h:410
#6 0x0001002d733b in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:1272
#7 0x000100219973 in php_execute_script (primary_file=0x7fff5fbff170) at
main.c:2476
[2011-12-15 20:37:07] scott...@php.net
Description:
Following code crashes.
Test script:
---
x; }
}
class Z extends Y {
function z() { return ++$this->x; }
}
$a = new Z();
$a->x();
--
Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #60536 [PATCH]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1 ID: 60536 Patch added by: g...@php.net Reported by:scott...@php.net Summary:Traits Segfault Status: Open Type: Bug Package:Scripting Engine problem Operating System: ubuntu 11.11 PHP Version:5.4SVN-2011-12-15 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: property006.phpt Revision: 1324052364 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property006.phpt&revision=1324052364 Previous Comments: [2011-12-16 16:19:08] g...@php.net The following patch has been added/updated: Patch Name: property005.phpt Revision: 1324052348 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property005.phpt&revision=1324052348 [2011-12-16 16:17:37] g...@php.net Hi Laruence: Your patch was also what I had thought of for the first moment, however, that is not actually fixing the bug. The problem is another one. For some reason the property value does not get set properly. At least that is my current understanding. This leads to either some inconsistent ref count, or an inappropriately shared zval. Haven't figured that out yet. What you patch does is just changing the semantics of when properties are composed into the class. That is also something that happens to be broken (inconsistent with normal inheritance). I have updated tests that should describe the correct semantics for property handling. If you see where I do something stupid with the zvals, please let me know. Thanks Stefan [2011-12-16 15:57:01] larue...@php.net The following patch has been added/updated: Patch Name: bug60536.phpt Revision: 1324051021 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.phpt&revision=1324051021 [2011-12-16 15:54:15] larue...@php.net The following patch has been added/updated: Patch Name: bug60536.patch Revision: 1324050855 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.patch&revision=1324050855 [2011-12-15 20:38:27] scott...@php.net backtrace: #0 0x000100289c71 in zend_mm_check_ptr (heap=0x10100, ptr=0x100c4f730, silent=1, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php- src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php- src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at zend_alloc.c:1380 #1 0x00010028c1ad in _zend_mm_free_int (heap=0x10100, p=0x100c4f730, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php- src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php- src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at zend_alloc.c:2064 #2 0x00010028de9d in _efree (ptr=0x100c4f730, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php- src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at zend_alloc.c:2436 #3 0x0001003742c8 in i_zval_ptr_dtor [inlined] () at /Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_execute.h:88 #4 0x0001003742c8 in ZEND_RETURN_SPEC_VAR_HANDLER (execute_data=0x1009802f8) at zend_execute.h:10833 #5 0x00010032a882 in execute (op_array=0x1009bad50) at zend_vm_execute.h:410 #6 0x0001002d733b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:1272 #7 0x000100219973 in php_execute_script (primary_file=0x7fff5fbff170) at main.c:2476 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60536 -- Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #60536 [PATCH]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1 ID: 60536 Patch added by: g...@php.net Reported by:scott...@php.net Summary:Traits Segfault Status: Open Type: Bug Package:Scripting Engine problem Operating System: ubuntu 11.11 PHP Version:5.4SVN-2011-12-15 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: property007.phpt Revision: 1324052379 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property007.phpt&revision=1324052379 Previous Comments: [2011-12-16 16:19:24] g...@php.net The following patch has been added/updated: Patch Name: property006.phpt Revision: 1324052364 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property006.phpt&revision=1324052364 [2011-12-16 16:19:08] g...@php.net The following patch has been added/updated: Patch Name: property005.phpt Revision: 1324052348 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property005.phpt&revision=1324052348 ---- [2011-12-16 16:17:37] g...@php.net Hi Laruence: Your patch was also what I had thought of for the first moment, however, that is not actually fixing the bug. The problem is another one. For some reason the property value does not get set properly. At least that is my current understanding. This leads to either some inconsistent ref count, or an inappropriately shared zval. Haven't figured that out yet. What you patch does is just changing the semantics of when properties are composed into the class. That is also something that happens to be broken (inconsistent with normal inheritance). I have updated tests that should describe the correct semantics for property handling. If you see where I do something stupid with the zvals, please let me know. Thanks Stefan [2011-12-16 15:57:01] larue...@php.net The following patch has been added/updated: Patch Name: bug60536.phpt Revision: 1324051021 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.phpt&revision=1324051021 [2011-12-16 15:54:15] larue...@php.net The following patch has been added/updated: Patch Name: bug60536.patch Revision: 1324050855 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.patch&revision=1324050855 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60536 -- Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #60536 [PATCH]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1 ID: 60536 Patch added by: g...@php.net Reported by:scott...@php.net Summary:Traits Segfault Status: Open Type: Bug Package:Scripting Engine problem Operating System: ubuntu 11.11 PHP Version:5.4SVN-2011-12-15 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: property008.phpt Revision: 1324054001 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property008.phpt&revision=1324054001 Previous Comments: [2011-12-16 16:19:39] g...@php.net The following patch has been added/updated: Patch Name: property007.phpt Revision: 1324052379 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property007.phpt&revision=1324052379 [2011-12-16 16:19:24] g...@php.net The following patch has been added/updated: Patch Name: property006.phpt Revision: 1324052364 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property006.phpt&revision=1324052364 ---- [2011-12-16 16:19:08] g...@php.net The following patch has been added/updated: Patch Name: property005.phpt Revision: 1324052348 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property005.phpt&revision=1324052348 -------- [2011-12-16 16:17:37] g...@php.net Hi Laruence: Your patch was also what I had thought of for the first moment, however, that is not actually fixing the bug. The problem is another one. For some reason the property value does not get set properly. At least that is my current understanding. This leads to either some inconsistent ref count, or an inappropriately shared zval. Haven't figured that out yet. What you patch does is just changing the semantics of when properties are composed into the class. That is also something that happens to be broken (inconsistent with normal inheritance). I have updated tests that should describe the correct semantics for property handling. If you see where I do something stupid with the zvals, please let me know. Thanks Stefan [2011-12-16 15:57:01] larue...@php.net The following patch has been added/updated: Patch Name: bug60536.phpt Revision: 1324051021 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.phpt&revision=1324051021 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60536 -- Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #60536 [Com]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1 ID: 60536 Comment by: g...@php.net Reported by:scott...@php.net Summary:Traits Segfault Status: Open Type: Bug Package:Scripting Engine problem Operating System: ubuntu 11.11 PHP Version:5.4SVN-2011-12-15 (SVN) Block user comment: N Private report: N New Comment: property008.phpt demonstrates the actual issue. Previous Comments: [2011-12-16 16:46:41] g...@php.net The following patch has been added/updated: Patch Name: property008.phpt Revision: 1324054001 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property008.phpt&revision=1324054001 [2011-12-16 16:19:39] g...@php.net The following patch has been added/updated: Patch Name: property007.phpt Revision: 1324052379 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property007.phpt&revision=1324052379 [2011-12-16 16:19:24] g...@php.net The following patch has been added/updated: Patch Name: property006.phpt Revision: 1324052364 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property006.phpt&revision=1324052364 ---- [2011-12-16 16:19:08] g...@php.net The following patch has been added/updated: Patch Name: property005.phpt Revision: 1324052348 URL: https://bugs.php.net/patch-display.php?bug=60536&patch=property005.phpt&revision=1324052348 -------- [2011-12-16 16:17:37] g...@php.net Hi Laruence: Your patch was also what I had thought of for the first moment, however, that is not actually fixing the bug. The problem is another one. For some reason the property value does not get set properly. At least that is my current understanding. This leads to either some inconsistent ref count, or an inappropriately shared zval. Haven't figured that out yet. What you patch does is just changing the semantics of when properties are composed into the class. That is also something that happens to be broken (inconsistent with normal inheritance). I have updated tests that should describe the correct semantics for property handling. If you see where I do something stupid with the zvals, please let me know. Thanks Stefan The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60536 -- Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #60717 [PATCH]: Order of traits in use statement can cause a fatal error
Edit report at https://bugs.php.net/bug.php?id=60717&edit=1
ID: 60717
Patch added by: g...@php.net
Reported by:Jared dot Williams1 at ntlworld dot com
Summary:Order of traits in use statement can cause a fatal
error
Status: Assigned
Type: Bug
Package:Class/Object related
Operating System: Ubuntu 11.10
PHP Version:5.4.0RC5
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: Fix-conflict-detection.patch
Revision: 1327964429
URL:
https://bugs.php.net/patch-display.php?bug=60717&patch=Fix-conflict-detection.patch&revision=1327964429
Previous Comments:
[2012-01-11 17:24:31] Jared dot Williams1 at ntlworld dot com
Description:
The fatal trigger only occurs when the order of the use statement is
class HTMLHelper implements Helper
{
use TextUTF8, TextArea, HTMLAttributes;
}
If the use statement is reordered...
class HTMLHelper implements Helper
{
use TextArea, HTMLAttributes, TextUTF8;
}
then code is fine.
I guess that some testing of abstract methods is missing somewhere?
Test script:
---
https://gist.github.com/1595674
Expected result:
No fatal error
Actual result:
--
PHP Fatal error: Can't inherit abstract function HTML\HTMLAttributes::text()
(previously declared abstract in HTML\TextArea) in
/var/www/framework.localhost/htdocs/bug.php on line 55
--
Edit this bug report at https://bugs.php.net/bug.php?id=60717&edit=1
Req #60911 [PATCH]: Confusing error message when extending traits
Edit report at https://bugs.php.net/bug.php?id=60911&edit=1 ID: 60911 Patch added by: g...@php.net Reported by:da...@php.net Summary:Confusing error message when extending traits Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: OSX 10.7.2 PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: extend-error-msg.patch Revision: 1328004117 URL: https://bugs.php.net/patch-display.php?bug=60911&patch=extend-error-msg.patch&revision=1328004117 Previous Comments: [2012-01-31 04:02:34] larue...@php.net actually this is difficult to achieve, think about: a.php index.php then you can not get any info of Foo while parsing index.php [2012-01-28 05:23:52] da...@php.net Description: While I know it should not be possible to have a trait extend another trait, the error message is confusing, stating that you are trying to extend a class. I understand that "use" is the correct answer to the problem the script is trying to solve. Test script: --- https://bugs.php.net/bug.php?id=60911&edit=1
Req #61265 [Com]: __autoload should know about traits
Edit report at https://bugs.php.net/bug.php?id=61265&edit=1 ID: 61265 Comment by: g...@php.net Reported by:manchokapitancho at gmail dot com Summary:__autoload should know about traits Status: Open Type: Feature/Change Request Package:Class/Object related PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Could you elaborate a bit on the usecase? Until now, there didn't seem to be the need to handle interfaces differently in an autoloader. Why would you treat traits differently from classes and interfaces? Previous Comments: [2012-03-03 13:10:25] manchokapitancho at gmail dot com Description: Currently, __autoload is automatically called when a class is not found. As of 5.4.0, it is also called when a trait is not found. It is also called when an interface is not found. Unfortunately, there is no way to understand what type of resource is being autoloaded. So I suggest that a second optional argument is added to __autoload. It can receive three possible values from the PHP engine - for example: AUTOLOAD_CLASS, AUTOLOAD_TRAIT and AUTOLOAD_INSTANCE. This way, a better autoload handling can be achieved. -- Edit this bug report at https://bugs.php.net/bug.php?id=61265&edit=1
Bug #64235 [Com]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1
ID: 64235
Comment by: g...@php.net
Reported by:imenem at inox dot ru
Summary:Insteadof not work for class method in 5.4.11
Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Debian GNU/Linux
PHP Version:5.4.11
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Hi:
The `insteadof` and `as` operators where not intended to be used with classes.
The syntax is intended to convey that the use operation is refined by
specifying how to
resolve conflicts __between__ traits.
That's the idea at least.
My solution for the initial problem presented would be to provide a method such
as follows in
the TestChildClass:
public function method() {
parent::method();
}
I understand that this is not ideal, and requires you to repeat yourself.
However, it is consistent in the sense that traits are traits and not classes,
and both get
mixed up as little as possible,
However, beside the academic notion of purity, I can see that
`TestParentClass::method
insteadof TestTrait;` is useful.
[I wonder whether `parent::method insteadof TestTrait;` should be supported as
well.]
Laruence's example with `TestParentClass::method as methodParent;` is however
problematic.
Traits are not supposed to conflict with classes, but with traits. So, allowing
the
introduction of aliases for method of the super class seems to me as something
that is
problematic, because it mixes up the concepts.
If you need an alias for the method of a parent class, the classic way would be:
public function foo() {
parent::bar();
}
No?
Well, that's my point of view.
So, from a practical point of view, referring to the parent (and only the
direct parent) class
in `insteadof` might be a useful/acceptable feature.
The use in conjunction with `as` seems to be something I would advocate against.
In either way, beside bugs that made this possible in the first place, I would
consider both
ideas as new features that need to be documented/discussed.
I thought that we had a test that only the traits listed in the `use` clause
can be used for
the `as`/`insteadof` operators, but that's either broken or not there, or a bug
that was fixed
in 5.4.11 as the original report suggests.
Therefore, from my perspective, 5.4.11 shows the behavior that's intended by
the spec/RFC.
Best regards
Stefan
Previous Comments:
[2013-02-20 08:22:01] larue...@php.net
reeze, *before* doesn't always means *RIGHT*.
[2013-02-20 08:16:52] re...@php.net
@laurence the code you paste above works the same as before:
http://3v4l.org/UpMCW#v5411 that didn't break
After read some doc I assume class is not suitable in context of 'insteadof',
so let's wait for Stefan or more discussion :)
[2013-02-20 08:12:40] larue...@php.net
form the context, insteadof works at class make sense.
reeze, whatever the RFC is, your fix simply skip check for classes at all,
which
will make the test script I paste result in "FATAL ERROR, undefined method",
that
is not acceptable.
[2013-02-20 08:07:58] larue...@php.net
The following patch has been added/updated:
Patch Name: bug64235.patch
Revision: 1361347678
URL:
https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.patch&revision=1361347678
[2013-02-20 08:04:11] dmi...@php.net
It's hard to say what is expected :)
I thought only traits may be used in context of "insteadof", now I'm not sure.
I sent the question to Stefan Marr. Lets wait for his opinion.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64235
--
Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1
Bug #62069 [Com]: binding wrong traits if they have same name methods
Edit report at https://bugs.php.net/bug.php?id=62069&edit=1 ID: 62069 Comment by: g...@php.net Reported by:larue...@php.net Summary:binding wrong traits if they have same name methods Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.4.3 Assigned To:dmitry Block user comment: N Private report: N New Comment: Hi Laruence: The first example is a bug, indeed. Why is the second example a bug? To me it looks like the perfectly intended traits semantics, no? Previous Comments: [2012-05-19 06:44:30] larue...@php.net and if the class have no own func method defination, the result will be: f2(); Expected result: >From T2 Actual result: -- >From T1 -- Edit this bug report at https://bugs.php.net/bug.php?id=62069&edit=1
[PHP-BUG] Bug #62204 [NEW]: Final keyword not enforced for methods from traits
From: gron Operating system: PHP version: 5.4Git-2012-06-01 (Git) Package: *Compile Issues Bug Type: Bug Bug description:Final keyword not enforced for methods from traits Description: Reported by Scott MacVicar on the mailing list (May 4th). Added here to not forget about it. > On 04 May 2012, at 20:30, Scott MacVicar wrote: > > This caused a few bugs for us / confusion. The final keyword is accepted inside a trait but it the class also defines a method without the final keyword this takes precedence. > > Two solutions: > Enforce final when a trait defines - https://whisky.macvicar.net/patches/0001- If-a-trait-declares-a-method- as-final-enforce-that.patch > > Prohibit final form being used in a trait - https://whisky.macvicar.net/patches/002-traits-Disable-use-of- final-keyword.patch > > I'm for the first solution here > > - S -- Edit bug report at https://bugs.php.net/bug.php?id=62204&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62204&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62204&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62204&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62204&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62204&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62204&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62204&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62204&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62204&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62204&r=support Expected behavior: https://bugs.php.net/fix.php?id=62204&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62204&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62204&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62204&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62204&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62204&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62204&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62204&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62204&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62204&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62204&r=mysqlcfg
Req #55266 [Com]: Traits vs Type hints
Edit report at https://bugs.php.net/bug.php?id=55266&edit=1
ID: 55266
Comment by: g...@php.net
Reported by:mchlpl at gmail dot com
Summary:Traits vs Type hints
Status: Open
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.4.0alpha2
Block user comment: N
Private report: N
New Comment:
My view on this issue is that traits do not constitute types and do not provide
interfaces. (I proposed the later one in the beginning in the sense of traits
are interfaces with implementation, but this was disregarded to make clear that
traits are neither classes nor interfaces.)
Thus, is_a should also not say anything about a trait.
Traits are not units of encapsulation, they do not guarantee to provide/protect
any invariants.
However, if you need to know what traits are used by a class, please refer to:
ReflectionClass::getTraits()
I just noticed that we have the following function in the SPL:
http://php.net/manual/en/function.class-implements.php
That should probably be mirrored to provide the same functionality as
ReflectionClass::getTraits().
Not sure what the design policies are here. From a symmetry perspective there
should be a class_uses() function, but from my personal perspective,
class_implements should get nuked and uses should transition to the reflection
extension if they need such meta programming facilities. Well, the later is not
practical, so we will probably need to have class_uses().
Previous Comments:
[2011-07-22 14:51:09] alex dot howansky at gmail dot com
> $a is not an instance of the trait but rather of
> the class that utilizes the trait.
You can say the same of interfaces and abstracts, but is_a returns true for
them.
Test script:
---
trait someTrait {}
interface someInterface {}
abstract class someAbstract {}
class someClass extends someAbstract implements someInterface {
use someTrait;
}
$a = new someClass();
var_dump(is_a($a, 'someClass'));
var_dump(is_a($a, 'someAbstract'));
var_dump(is_a($a, 'someInterface'));
var_dump(is_a($a, 'someTrait'));
Expected result:
bool(true)
bool(true)
bool(true)
bool(?)
Actual result:
bool(true)
bool(true)
bool(true)
bool(false)
[2011-07-22 14:50:36] mchlpl at gmail dot com
Mike: That's one way of looking at it. My point of view is that a trait adds
methods to class' interface (where interface is a set of public members of a
class - both methods and fields) and this should be reflected in class type.
Currently (unless I missed something that was not mentioned in RFC - I admit to
not have gone through SVN version of docs) there seem to be no way to check if
class uses a trait or no. Only new functions mentioned are trait_exists() and
get_declared_traits(). Checking if the object has a method will not work, if
trait is meant to override method in host class. Having traits reflected in
object's type, would solve this problem nicely. Adding another function to
glabal namespace (uses_trait() ?) is not something I would like to see.
[2011-07-22 13:36:59] me at mikestowe dot com
I believe this is the correct result as $a is not an instance of the trait but
rather of the class that utilizes the trait.
[2011-07-22 07:44:34] mchlpl at gmail dot com
Description:
Traits, when used in a class, are not added to class' type, and therefore can
not be use in type hints. The RFCs on traits https://wiki.php.net/rfc/traits
and on horizontal reuse https://wiki.php.net/rfc/horizontalreuse do not explain
if this is by design.
On the other hand Traits seem to share the same namespace as Classes and
Interfaces, since it is impossible to have an Interface and a Trait that share
the name ('Fatal error: Cannot redeclare class' is raised when this is
attempted).
Test script:
---
https://bugs.php.net/bug.php?id=55266&edit=1
Bug #54441 [Com]: Traits - Visibility on alias names
Edit report at https://bugs.php.net/bug.php?id=54441&edit=1
ID: 54441
Comment by: g...@php.net
Reported by:php-svn at helio dot arq dot br
Summary:Traits - Visibility on alias names
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:trunk-SVN-2011-04-01 (snap)
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
Hm, today I feel like it is not a good idea to allow
use Foo {
Foo::lol as dontKnow;
dontKnow as protected;
}
Because we will end up with chains like this:
use Foo {
Foo::lol as dontKnow;
dontKnow as foo;
foo as bar;
bar as baz;
}
And I do not see the use case for it, while I see readability problems.
This is all equivalent to:
use Foo {
Foo::lol as dontKnow;
Foo::lol as foo;
Foo::lol as bar;
Foo::lol as baz;
}
Which IMHO is a lot clearer. Every level of indirection is another level of
added complexity, and I do not see a relevant use case at the moment.
So, I will regard this as something that should not work.
Not sure yet how to design it properly. Will look at it.
Previous Comments:
[2011-07-22 13:33:19] me at mikestowe dot com
class Boo {
use Foo {
Foo::lol as dontKnow;
dontKnow as protected;
}
}
To me this would do the following:
Use "Foo", set "Foo:lol" as "dontKnow", and then set "dontKnow" as "protected"
Meaning that I should be able to call $boo->lol, $boo->dontKnow, or
$boo->protected to accomplish the same thing.
Otherwise it should throw a method does not exist error if the "as" is supposed
to rename the function.
[2011-04-03 15:30:16] php at stefan-marr dot de
Interesting question.
I suppose it could be legal (but obviously it is currently not implemented).
It looks kind of ugly to me, since it is less concise.
But well, all the traits use definitions should be declarative and orderless,
so
if it is possible to do something with two separate declarations then people
might expect that it works.
Not sure whether we want that...
But anyway, a good catch, thanks.
Stefan
[2011-04-02 18:14:36] fel...@php.net
According to the actual grammar and implementation, the right way to do this is
using:
Foo::lol as protected dontKnow;
Stefan Marr, is supposed to work the code as the bug reporter tried it?
[2011-04-01 12:47:43] php-svn at helio dot arq dot br
Description:
I'm trying Traits in php-trunk version.
In a give moment, I tried to change visibility in a alias trait's method.
Test script:
---
trait Foo {
public static function lol() {
echo 'Foo!';
}
}
class Boo {
use Foo {
Foo::lol as dontKnow;
dontKnow as protected;
}
}
$boo = new Boo();
$boo->dontKnow();
Expected result:
Fatal error: Call to protected method Boo::dontKnow() from context '' in %s on
line %d
Actual result:
--
Foo!
--
Edit this bug report at https://bugs.php.net/bug.php?id=54441&edit=1
Bug #55214 [PATCH]: use of __CLASS__ within trait returns trait name not class name
Edit report at https://bugs.php.net/bug.php?id=55214&edit=1
ID: 55214
Patch added by: g...@php.net
Reported by:chris dot rutledge at gmail dot com
Summary:use of __CLASS__ within trait returns trait name not
class name
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu
PHP Version:5.4.0alpha1
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: __CLASS__-in-traits.patch
Revision: 1311443128
URL:
https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.patch&revision=1311443128
Previous Comments:
[2011-07-23 14:17:24] fel...@php.net
It's simple to add the __TRAIT__ one, just like __CLASS__ does.
But making a more magic __CLASS__ to reflect the class that called is too much
magic, hacky. Whereas we are currently doing the __CLASS__ substitution on
compile-time.
[2011-07-22 04:56:04] g...@php.net
Felipe: I tend to disagree, too.
I do not think this is expected behavior.
Will have a look at this, and another bug reported on the QA mailing list
hopefully at the weekend.
Best regards
Stefan
[2011-07-15 06:44:47] chris dot rutledge at gmail dot com
It may be expected from the point of view of those developing the 5.4 branch,
but
logically this approach seems flawed.
As one big advantage of traits seems to be as a replacement for
copy-and-pasting
code, maybe consider making __CLASS__ have the value of the class that called
the
trait and a new magic constant __TRAIT__ with the trait name?
[2011-07-15 06:32:57] fel...@php.net
This is the expected behavior. It just need be documented.
[2011-07-15 06:30:34] chris dot rutledge at gmail dot com
Description:
use of __CLASS__ within trait returns trait name not class name.
Test script:
---
trait Singleton {
private static $instance;
public static function Load() {
if(!isset(self::$instance)) {
$c = __CLASS__;
self::$instance = new $c;
}
return self::$instance;
}
}
class Test {
use Singleton;
private function __construct() { }
}
Test::Load();
Expected result:
Expected __CLASS__ to return the name of the class that required the trait
('Test'), so that the singleton object could be instantiated
Actual result:
--
__CLASS__ returned 'Singleton', this caused a Fatel error:
Fatal error: Cannot instantiate trait Singleton in
/home/dshed/public/northie/index.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=55214&edit=1
Bug #55214 [Com]: use of __CLASS__ within trait returns trait name not class name
Edit report at https://bugs.php.net/bug.php?id=55214&edit=1 ID: 55214 Comment by: g...@php.net Reported by:chris dot rutledge at gmail dot com Summary:use of __CLASS__ within trait returns trait name not class name Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Ubuntu PHP Version:5.4.0alpha1 Assigned To:gron Block user comment: N Private report: N New Comment: I attached a patch of how a fix could be done. I have to admit that it is hacky, but I think this is the expected behavior with respect to the metaphor of compiler assisted copy'n'past. However, the patch is problematic, since it introduces a new memory leak. And I do not have a good strategy yet to fix it. Not sure how another patch could work, but the general idea is that __CLASS__ is not actually defined inside a trait (BTW: we should add __TRAIT__, too, yes). Thus, it resolves to a IS_NULL value. And as it happens to be, IS_NULL makes all is data members invalid, and I use that to indicate that it isn't actually a NULL value but that I want to fix it up with the class name when the method is actually flattened/copied into the class. The problem with the memory leak comes from the fact that copying the method is not actually done deeply but shallow. And, I do not know how to free only my fixed up names/ZVALs :-/. Previous Comments: [2011-07-23 17:45:28] g...@php.net The following patch has been added/updated: Patch Name: __CLASS__-in-traits.patch Revision: 1311443128 URL: https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.patch&revision=1311443128 [2011-07-23 14:17:24] fel...@php.net It's simple to add the __TRAIT__ one, just like __CLASS__ does. But making a more magic __CLASS__ to reflect the class that called is too much magic, hacky. Whereas we are currently doing the __CLASS__ substitution on compile-time. ---- [2011-07-22 04:56:04] g...@php.net Felipe: I tend to disagree, too. I do not think this is expected behavior. Will have a look at this, and another bug reported on the QA mailing list hopefully at the weekend. Best regards Stefan [2011-07-15 06:44:47] chris dot rutledge at gmail dot com It may be expected from the point of view of those developing the 5.4 branch, but logically this approach seems flawed. As one big advantage of traits seems to be as a replacement for copy-and-pasting code, maybe consider making __CLASS__ have the value of the class that called the trait and a new magic constant __TRAIT__ with the trait name? [2011-07-15 06:32:57] fel...@php.net This is the expected behavior. It just need be documented. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55214 -- Edit this bug report at https://bugs.php.net/bug.php?id=55214&edit=1
Bug #55214 [PATCH]: use of __CLASS__ within trait returns trait name not class name
Edit report at https://bugs.php.net/bug.php?id=55214&edit=1 ID: 55214 Patch added by: g...@php.net Reported by:chris dot rutledge at gmail dot com Summary:use of __CLASS__ within trait returns trait name not class name Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Ubuntu PHP Version:5.4.0alpha1 Assigned To:gron Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: __CLASS__-in-traits.002.patch Revision: 1311532096 URL: https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.002.patch&revision=1311532096 Previous Comments: [2011-07-23 17:53:25] g...@php.net I attached a patch of how a fix could be done. I have to admit that it is hacky, but I think this is the expected behavior with respect to the metaphor of compiler assisted copy'n'past. However, the patch is problematic, since it introduces a new memory leak. And I do not have a good strategy yet to fix it. Not sure how another patch could work, but the general idea is that __CLASS__ is not actually defined inside a trait (BTW: we should add __TRAIT__, too, yes). Thus, it resolves to a IS_NULL value. And as it happens to be, IS_NULL makes all is data members invalid, and I use that to indicate that it isn't actually a NULL value but that I want to fix it up with the class name when the method is actually flattened/copied into the class. The problem with the memory leak comes from the fact that copying the method is not actually done deeply but shallow. And, I do not know how to free only my fixed up names/ZVALs :-/. ---- [2011-07-23 17:45:28] g...@php.net The following patch has been added/updated: Patch Name: __CLASS__-in-traits.patch Revision: 1311443128 URL: https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.patch&revision=1311443128 [2011-07-23 14:17:24] fel...@php.net It's simple to add the __TRAIT__ one, just like __CLASS__ does. But making a more magic __CLASS__ to reflect the class that called is too much magic, hacky. Whereas we are currently doing the __CLASS__ substitution on compile-time. -------- [2011-07-22 04:56:04] g...@php.net Felipe: I tend to disagree, too. I do not think this is expected behavior. Will have a look at this, and another bug reported on the QA mailing list hopefully at the weekend. Best regards Stefan [2011-07-15 06:44:47] chris dot rutledge at gmail dot com It may be expected from the point of view of those developing the 5.4 branch, but logically this approach seems flawed. As one big advantage of traits seems to be as a replacement for copy-and-pasting code, maybe consider making __CLASS__ have the value of the class that called the trait and a new magic constant __TRAIT__ with the trait name? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55214 -- Edit this bug report at https://bugs.php.net/bug.php?id=55214&edit=1
Bug #55214 [Com]: use of __CLASS__ within trait returns trait name not class name
Edit report at https://bugs.php.net/bug.php?id=55214&edit=1 ID: 55214 Comment by: g...@php.net Reported by:chris dot rutledge at gmail dot com Summary:use of __CLASS__ within trait returns trait name not class name Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Ubuntu PHP Version:5.4.0alpha1 Assigned To:gron Block user comment: N Private report: N New Comment: Ok, updated the patch and would like to ask for a review. This is still hacky, but now I use the literals of a function to be able to clean up the zval for the __CLASS__ name. Thus, the memory leak should be fixed. Think we will still need a __TRAIT__ to mirror __CLASS__ and to get the trait name itself when that is required. The test case is missing in the patch: --TEST-- Bug #55214 (Use of __CLASS__ within trait returns trait name not class name) --FILE-- get_class_name_obj(); var_dump($r); ?> --EXPECT-- string(9) "SomeClass" string(9) "SomeClass" Previous Comments: ---- [2011-07-24 18:28:16] g...@php.net The following patch has been added/updated: Patch Name: __CLASS__-in-traits.002.patch Revision: 1311532096 URL: https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.002.patch&revision=1311532096 ---- [2011-07-23 17:53:25] g...@php.net I attached a patch of how a fix could be done. I have to admit that it is hacky, but I think this is the expected behavior with respect to the metaphor of compiler assisted copy'n'past. However, the patch is problematic, since it introduces a new memory leak. And I do not have a good strategy yet to fix it. Not sure how another patch could work, but the general idea is that __CLASS__ is not actually defined inside a trait (BTW: we should add __TRAIT__, too, yes). Thus, it resolves to a IS_NULL value. And as it happens to be, IS_NULL makes all is data members invalid, and I use that to indicate that it isn't actually a NULL value but that I want to fix it up with the class name when the method is actually flattened/copied into the class. The problem with the memory leak comes from the fact that copying the method is not actually done deeply but shallow. And, I do not know how to free only my fixed up names/ZVALs :-/. -------- [2011-07-23 17:45:28] g...@php.net The following patch has been added/updated: Patch Name: __CLASS__-in-traits.patch Revision: 1311443128 URL: https://bugs.php.net/patch-display.php?bug=55214&patch=__CLASS__-in-traits.patch&revision=1311443128 [2011-07-23 14:17:24] fel...@php.net It's simple to add the __TRAIT__ one, just like __CLASS__ does. But making a more magic __CLASS__ to reflect the class that called is too much magic, hacky. Whereas we are currently doing the __CLASS__ substitution on compile-time. ---- [2011-07-22 04:56:04] g...@php.net Felipe: I tend to disagree, too. I do not think this is expected behavior. Will have a look at this, and another bug reported on the QA mailing list hopefully at the weekend. Best regards Stefan The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55214 -- Edit this bug report at https://bugs.php.net/bug.php?id=55214&edit=1
[PHP-BUG] Bug #55524 [NEW]: Traits should not be able to extend a class
From: gron
Operating system:
PHP version: 5.4.0alpha3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Traits should not be able to extend a class
Description:
Spotted by this post: http://zuttonet.com/articles/php-class-traits/
Traits build their own hierarchy of uses, but there is no useful semantics
for
extending classes.
For instance:
trait Foo extends Base {
function bar() {}
}
The semantics for that is not defined (and actually at least broken for
abstract
methods).
This should give a fatal error as would the other way around (Base extends
Foo).
Test script:
---
trait Foo extends Base {
function bar() {}
}
Expected result:
Fatal error: A trait (Foo) cannot extend a class (Base) in %s on line %d
--
Edit bug report at https://bugs.php.net/bug.php?id=55524&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55524&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55524&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55524&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55524&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55524&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55524&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55524&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55524&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55524&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55524&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55524&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55524&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55524&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55524&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55524&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55524&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55524&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55524&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55524&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55524&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55524&r=mysqlcfg
Bug #55554 [Com]: Trait methods overriding legacy constructors
Edit report at https://bugs.php.net/bug.php?id=4&edit=1
ID: 4
Comment by: g...@php.net
Reported by:ryan at zuttonet dot com
Summary:Trait methods overriding legacy constructors
Status: Open
Type: Bug
Package:*Programming Data Structures
Operating System: Ubuntu
PHP Version:5.4.0alpha3
Block user comment: N
Private report: N
New Comment:
Hi Ryan:
I am sorry, I don't think I understand what inconsistency you are pointing out.
Could you elaborate on the problem?
(And please include the code you are referring to directly here. Just to make
it
easier for me
to know that we are talking about exactly the same code.)
What I understand is you want to provide the constructor with a trait, right?
Like this:
The problem I see here is that for MyClass2 the constructor does not actually
get registered
as a constructor but just as a normal method.
That seems to be an inconsistency that needs to be fixed.
Ok, now to the new vs. legacy constructors:
class Bar {
function Bar() {
echo "BarBar new ctor\n";
}
function __construct() {
echo "Bar new ctor\n";
}
}
$o = new Bar;
?>
Switching the order of the definition of the constructors doesn't influence the
result,
__construct always wins.
Both your examples behaves identical to the situation if the __construct would
have been
defined directly in the class. So, where is the problem here?
It is not an inconsistency with how PHP behaves without traits, from what I can
see.
Ah, and please try the latest code in the SVN, I am not exactly sure whether I
changed
anything that could be related to that between alpha3 and now. But I doubt it.
Thanks
Stefan
Previous Comments:
[2011-08-31 15:52:43] ryan at zuttonet dot com
Apologies; the literal expected output for the provided test scripts should be:
"this is a constructor"
As this is the output when using __construct() in the class definition instead
of
a legacy-style constructor.
[2011-08-31 15:49:30] ryan at zuttonet dot com
Description:
For the sake of consistency, exactly one of the following should be implemented:
1. Trait methods should be able to override __construct definitions
2. Trait methods should not be able to override legacy constructor definitions
Currently, trait methods are not able to override __construct
definitions. Trait methods are able to override legacy constructor definitions.
Test script:
---
Here are two test cases that will reproduce the defect:
https://gist.github.com/1183844
Expected result:
A trait-level __construct method (or a trait-level method aliased as
__construct)
should not be able to override any type of constructor in a class
Actual result:
--
Fatal error: Call to private SomeClass::__construct() from invalid context
--
Edit this bug report at https://bugs.php.net/bug.php?id=4&edit=1
Req #55613 [Com]: Feature: Trait checks type of consuming class
Edit report at https://bugs.php.net/bug.php?id=55613&edit=1 ID: 55613 Comment by: g...@php.net Reported by:wil dot moore at wimoore dot com Summary:Feature: Trait checks type of consuming class Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Mac (Darwin 10.8.0 i386) PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: So far the community was opposed to 'requiring' interfaces from using classes. However, you can always express 'require' relationships to individual methods by adding them as abstract methods to the trait. >From my point of view that is also the way to go, since traits do not preserve >your invariants, and are meant for code reuse only. Thus, if you imply a certain invariants with an interface, that is not enforced by a trait. A trait can require a certain method to be available since it will be using it, and you might want that to be check at compile time, but a trait does not promise to obey a certain set of requirements on invariants. Please consider using composition and classes if you have strong requirements on how to interact with an object. Previous Comments: [2011-09-06 01:10:51] wil dot moore at wimoore dot com Description: For instance, one may require that the use of a trait "requires" that the consuming class must be of a certain type or implement a specific interface. An example is Doctrine2's ArrayCollection. One may want to write a utility trait that mixes in functionality that is useful to this type of Collection. This trait would work with ArrayCollections or its decedents but would throw an Exception (i.e. TraitConsumerIllegalTypeException) if attempting to use with other types of classes. -- Edit this bug report at https://bugs.php.net/bug.php?id=55613&edit=1
Bug #60165 [Com]: Overriding unexisting trait should throw/trigger the exception/error
Edit report at https://bugs.php.net/bug.php?id=60165&edit=1
ID: 60165
Comment by: g...@php.net
Reported by:fruit dot dev at gmail dot com
Summary:Overriding unexisting trait should throw/trigger the
exception/error
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Fedora 14
PHP Version:5.4.0beta2
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
Thanks for the reminder.
The patch is below.
As soon as I find another half an hour, I will add the necessary tests and
commit.
Best regards
Stefan
--- Zend/zend_compile.c (revision 319357)
+++ Zend/zend_compile.c (working copy)
@@ -4036,6 +4036,8 @@
size_t i, j = 0;
zend_trait_precedence *cur_precedence;
zend_trait_method_reference *cur_method_ref;
+ char *lcname;
+ bool aliased_method_exists;
/* resolve class references */
if (ce->trait_precedences) {
@@ -4064,6 +4066,15 @@
if (ce->trait_aliases[i]->trait_method->class_name) {
cur_method_ref = ce->trait_aliases[i]-
>trait_method;
cur_method_ref->ce =
zend_fetch_class(cur_method_ref->class_name, cur_method_ref->cname_len,
ZEND_FETCH_CLASS_TRAIT TSRMLS_CC);
+
+ /** Ensure that this reference is resolvable */
+ lcname = zend_str_tolower_dup(cur_method_ref-
>method_name, cur_method_ref->mname_len);
+ aliased_method_exists =
zend_hash_exists(&cur_method_ref->ce->function_table, lcname, cur_method_ref-
>mname_len + 1);
+ efree(lcname);
+
+ if (!aliased_method_exists) {
+ zend_error(E_COMPILE_ERROR, "An alias
was defined for %s::%s but this method does not exist", cur_method_ref->ce-
>name, cur_method_ref->method_name);
+ }
}
i++;
}
Previous Comments:
[2011-10-28 21:23:56] fruit dot dev at gmail dot com
Description:
In case, when user overrides invalid traits method, PHP should check whether
specified method belongs to given trait.
The code given below is valid for preprocessing. Meanwhile trait "A" does not
have method "getTitle", as well as trait "B" does contains "getSlug" method.
I guess, PHP should trigger error telling about the user is entangled among the
three pines.
Test script:
---
trait A
{
public function getSlug ()
{
return $this->slug;
}
}
trait B
{
public function getTitle ()
{
return $this->title;
}
}
class Foo
{
protected $slug, $title;
use A, B
{
A::getTitle as title;
B::getSlug as slug;
}
}
$object = new Foo();
Expected result:
Error/exception should be triggered/thrown
Actual result:
--
silence (no errors was shown)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60165&edit=1
[PHP-BUG] Bug #60338 [NEW]: SplFixedArray::key returns index for invalid keys
From: gooh Operating system: PHP version: 5.4SVN-2011-11-19 (SVN) Package: SPL related Bug Type: Bug Bug description:SplFixedArray::key returns index for invalid keys Description: SplFixedArray::key() will return a value even when the key does not exist in the SplFixedArray. This does not conform to the behavior we have in regular arrays, ArrayObject and ArrayIterator. SplFixedArray::key() should return NULL when the current key does not exist to conform. Test script: --- http://codepad.viper-7.com/4hWmUn Expected result: NULL NULL NULL NULL Actual result: -- int(3) NULL NULL NULL -- Edit bug report at https://bugs.php.net/bug.php?id=60338&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60338&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60338&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60338&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60338&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60338&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60338&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60338&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60338&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60338&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60338&r=support Expected behavior: https://bugs.php.net/fix.php?id=60338&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60338&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60338&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60338&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60338&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60338&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60338&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60338&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60338&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60338&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60338&r=mysqlcfg
Bug #60338 [Com]: SplFixedArray::key returns index for invalid keys
Edit report at https://bugs.php.net/bug.php?id=60338&edit=1 ID: 60338 Comment by: g...@php.net Reported by: g...@php.net Summary:SplFixedArray::key returns index for invalid keys Status: Open Type: Bug Package:SPL related PHP Version:5.4SVN-2011-11-19 (SVN) Block user comment: N Private report: N New Comment: Apparently the Expected Output is achieved when using key() instead of SplFixedArray::key(). See http://codepad.viper-7.com/I3REjD. Thanks to NikiC for pointing it out. Previous Comments: [2011-11-19 13:32:44] g...@php.net Description: SplFixedArray::key() will return a value even when the key does not exist in the SplFixedArray. This does not conform to the behavior we have in regular arrays, ArrayObject and ArrayIterator. SplFixedArray::key() should return NULL when the current key does not exist to conform. Test script: --- http://codepad.viper-7.com/4hWmUn Expected result: NULL NULL NULL NULL Actual result: -- int(3) NULL NULL NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=60338&edit=1
Bug #60369 [Com]: Crash with static property in trait
Edit report at https://bugs.php.net/bug.php?id=60369&edit=1
ID: 60369
Comment by: g...@php.net
Reported by:vr...@php.net
Summary:Crash with static property in trait
Status: Verified
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.4.0RC1
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
Thanks. I just missed the statics here.
Patch below, svn commit coming as soon as the tests have completed.
Thanks for the catch.
Index: Zend/zend_compile.c
===
--- Zend/zend_compile.c (revision 319492)
+++ Zend/zend_compile.c (working copy)
@@ -4271,10 +4286,11 @@
/* this one is inherited, lets look it
up in its own class */
zend_hash_quick_find(&coliding_prop->ce->properties_info, prop_name,
prop_name_length+1,
prop_hash, (void **) &coliding_prop);
}
- if ((coliding_prop->flags & ZEND_ACC_PPP_MASK)
== (property_info->flags & ZEND_ACC_PPP_MASK)) {
+ if ( (coliding_prop->flags &
(ZEND_ACC_PPP_MASK | ZEND_ACC_STATIC))
+ == (property_info->flags &
(ZEND_ACC_PPP_MASK | ZEND_ACC_STATIC))) {
/* flags are identical, now the value
needs to be checked */
if (property_info->flags &
ZEND_ACC_STATIC) {
-not_compatible = (FAILURE == compare_function(&compare_result,
+ not_compatible = (FAILURE ==
compare_function(&compare_result,
ce->default_static_members_table[coliding_prop->offset],
ce->traits[i]->default_static_members_table[property_info->offset] TSRMLS_CC))
|| (Z_LVAL(compare_result) != 0);
Previous Comments:
[2011-11-23 20:38:53] vr...@php.net
Backtrace:
Entry point php!mainCRTStartup
Create time 11/23/2011 12:31:14 PM
Time spent in user mode 0 Days 0:0:0.15
Time spent in kernel mode 0 Days 0:0:0.0
Function Arg 1 Arg 2 Arg 3 Source
ntdll!ZwRaiseException+12 009ce3c4 009ce414
ntdll!KiUserExceptionDispatcher+2a 0023 009cfb08 002b
php5!_php_import_environment_variables+39f 0023 009cfb08
002b
php5!_php_import_environment_variables+39f
PHP5!ZEND_DO_BEGIN_CATCH+244In
php__PID__8020__Date__11_23_2011__Time_12_31_24PM__22__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_do_begin_catch+244 in C:\Program Files
(x86)\PHP 5.4\php5.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location 0x on
thread 0
[2011-11-23 20:35:18] vr...@php.net
Description:
PHP crashes when there is a static property defined in a trait plus there is a
normal property of the same name in a class using this trait.
Test script:
---
Expected result:
Exit code: 0
Actual result:
--
Exit code: -1073741819
--
Edit this bug report at https://bugs.php.net/bug.php?id=60369&edit=1
Req #63629 [Com]: New constant __ALIAS__ for trait functions to know how they were called
Edit report at https://bugs.php.net/bug.php?id=63629&edit=1 ID: 63629 Comment by: g...@php.net Reported by:spamfreedave-zend at yahoo dot com Summary:New constant __ALIAS__ for trait functions to know how they were called Status: Feedback Type: Feature/Change Request Package:*General Issues Operating System: Mac OSX PHP Version:5.4.9 Block user comment: N Private report: N New Comment: What about: $backtrace=debug_backtrace(); echo $backtrace[0]['function']; That seems to be also the common solution for getting the name of the calling function. Previous Comments: [2012-11-28 09:50:56] larue...@php.net could you explain a little more: what i " some interesting dynamic behavior" ? I mean , the real use case. [2012-11-27 18:52:27] spamfreedave-zend at yahoo dot com Description: I would like my trait functions to know what alias (if any) was used to call them. The idea came from discovering that you can give a trait function multiple aliases (see Test Script). It occurs to me that you could have some interesting dynamic behavior if the trait function was able to determine what name (alias) was used to call it. If possible, a new constant __ALIAS__ could be created to store this value. Thank you for your consideration. Test script: --- test1(); $c->test2(); Expected result: test, test1 test, test2 Actual result: -- test, __ALIAS__ test, __ALIAS__ -- Edit this bug report at https://bugs.php.net/bug.php?id=63629&edit=1
