[PHP-BUG] Req #63668 [NEW]: Unable to replicate method signature if the method uses "self"
From: dev at jurajsplayground dot com
Operating system: Linux/GNU
PHP version: 5.4.9
Package: Reflection related
Bug Type: Feature/Change Request
Bug description:Unable to replicate method signature if the method uses "self"
Description:
I was trying to mock a ZF class using PHPUnit which has a method that hints
a
parameter as "self" rather than using the class name.
ReflectionParameter::getClass() returns the correct class name, however,
there
is no way to find out that the actual method signature used "self" rather
than
the class name.
See:
https://github.com/sebastianbergmann/phpunit-mock-objects/issues/107
https://github.com/zendframework/zf2/issues/2977
While this behaviour is expected, using echo() on the parameters outputs
"Parameter #0 [ self $merge ]" (we can see it's not "Config" but
"self") while using getClass() returns the "self" turned into
ReflectionClass.
Could another method be added to ReflectionParameter that returns the raw
"type
hint", i.e. "self" so that method's signature can be properly replicated
for
testing?
Test script:
---
class Config {
public function merge(self $merge){
}
}
$ref = new ReflectionMethod("Config", "merge");
echo current($ref->getParameters()) , " ",
current($ref->getParameters())->getClass()->name;
--
Edit bug report at https://bugs.php.net/bug.php?id=63668&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63668&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63668&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63668&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63668&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63668&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63668&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63668&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63668&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63668&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63668&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63668&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63668&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63668&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63668&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63668&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63668&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63668&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63668&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63668&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63668&r=mysqlcfg
Bug #45910 [Com]: Cannot declare self-referencing constant
Edit report at https://bugs.php.net/bug.php?id=45910&edit=1
ID: 45910
Comment by: semnanweb at gmail dot com
Reported by:s dot tretter at szene1 dot at
Summary:Cannot declare self-referencing constant
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.0alpha1
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
same problem on php 5.4.8 apc 1.3.13
http://stackoverflow.com/questions/13272981/cannot-declare-self-referencing-constant/
the bugs for apc. but i need apc. i must restart apache for working sometimes
and then same error. restart after some times error and etc ... :(
Previous Comments:
[2008-08-26 08:38:45] dmi...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-08-25 19:58:46] fel...@php.net
I've added two tests (bug45910.phpt, bug45910_2.phpt), the latter segfaults.
(5_3 and HEAD)
[2008-08-25 19:28:11] fel...@php.net
Here's a simple script based in your example:
class foo {
const AAA = 'x';
const BBB = 'a';
const CCC = 'a';
const DDD = self::AAA;
private static $foo = array(
self::BBB => 'a',
self::CCC => 'b',
self::DDD => self::AAA
);
public static function test() {
self::$foo;
}
}
foo::test();
The error is only issued when BBB and CCC contains same value.
[2008-08-25 18:34:38] s dot tretter at szene1 dot at
okay here a test script...
array(
self::CONTENT_AD=>
'n64',
self::CONTENT_AD_MAIN =>
'n63',
self::CONTENT_AD_SALE =>
'n65',
self::SKYSCRAPER=>
'n62',
self::SITEBAR =>
'n66',
self::BIGSIZE_BANNER=>
'n61',
self::HOCKEY1_SKYSCRAPER
=> 'n62',
self::HOCKEY2_BIGSIZE_BANNER=>
'n61',
self::SPECIAL_FOTO_SKYSCRAPER =>
'n67',
self::CONTENT_USERPAGE =>
self::NOSHOW
)
);
public static $objects = array();
public static function addElement($object)
{
self::$objects[] = $object;
}
}
Test::addElement("socha");
?>
[2008-08-25 18:10:42] s dot tretter at szene1 dot at
Description:
The problem is that the same script worked in php5.2.6, but in php5.3 it
results in a "Fatal error: Cannot declare self-referencing constant 'n61' in
..."
There is an array that uses many constants to set the array with values. If I
execute a method of the class this error message stops the execution..but the
line of the code has nothing todo with this array! strange error... just let me
send my test code, u will see it yourself.
If i modify the array, remove the lines that php is complain about, some lines
and so on.. it works.. but these lines are not differnt to the ohter lines..!?
I don't understand it.
Also tried with latest cvs snapshot
Reproduce code:
---
I have a test script, but I don't wanna publish the code... May I send it
directly to a php developer?
Expected result:
like in php5.2.6 this code should work!
Actual result:
--
Fatal error: Cannot declare self-referencing constant 'n61' in //test.php
on line 132
--
Edit this bug report at https://bugs.php.net/bug.php?id=45910&edit=1
Bug #63646 [Wfx]: Trait method names matching classes that use said trait treated as constructors
Edit report at https://bugs.php.net/bug.php?id=63646&edit=1 ID: 63646 User updated by:phpbugs at catchall dot drarok dot com Reported by:phpbugs at catchall dot drarok dot com Summary:Trait method names matching classes that use said trait treated as constructors Status: Wont fix Type: Bug Package:Scripting Engine problem Operating System: OS X 10.8 PHP Version:master-Git-2012-11-29 (Git) Block user comment: N Private report: N New Comment: @nikic: precisely what I was thinking! Previous Comments: [2012-12-01 12:19:10] ni...@php.net @laruence: On the other hand, if you are using a namespaced class old-style constructors aren't used either. So the same might also be done with traits. [2012-12-01 11:31:06] larue...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php the method name same as class name is considered as constructor as of PHP 5.4 although we encourage use __construct instead of that. but it should also be compatible [2012-11-29 09:48:49] phpbugs at catchall dot drarok dot com Description: If you use a Trait which has a method name matching your class name, it is used as an old-style constructor in the case where the using class doesn't define a constructor. If you *do* define a constructor, you receive the error "Fatal error: Hello has colliding constructor definitions coming from traits". Test script: --- https://bugs.php.net/bug.php?id=63646&edit=1
Req #54123 [Com]: Built-in LINQ-style query support for objects
Edit report at https://bugs.php.net/bug.php?id=54123&edit=1 ID: 54123 Comment by: id2639730 at gmail dot com Reported by:dave dot mulford at gmail dot com Summary:Built-in LINQ-style query support for objects Status: Open Type: Feature/Change Request Package:*Database Functions Operating System: Linux / Windows PHP Version:5.3.6RC1 Block user comment: N Private report: N New Comment: +1 for this feature. I would like to have the support custom LINQ provider like c# LinqToSql, LinqToXML, etc... Previous Comments: [2011-02-28 21:23:54] dave dot mulford at gmail dot com Description: Having a php native LINQ-style of querying objects in PHP would make code more maintainable and readable. As of now, developers must loop through an array of objects and perform manual filtering, grouping, etc. Here is a link to Microsoft's examples of using LINQ: http://msdn.microsoft.com/en-us/vcsharp/aa336746 -- Edit this bug report at https://bugs.php.net/bug.php?id=54123&edit=1
Req #54123 [Opn]: Built-in LINQ-style query support for objects
Edit report at https://bugs.php.net/bug.php?id=54123&edit=1 ID: 54123 User updated by:dave dot mulford at gmail dot com Reported by:dave dot mulford at gmail dot com Summary:Built-in LINQ-style query support for objects Status: Open Type: Feature/Change Request Package:*Database Functions Operating System: Linux / Windows PHP Version:5.3.6RC1 Block user comment: N Private report: N New Comment: I had forgotten all about this request. If you're interested in trying it out, I have started a php LINQ project, called php-iq. Here is the github link for it: https://github.com/mw007/php-iq Previous Comments: [2012-12-02 14:25:28] id2639730 at gmail dot com +1 for this feature. I would like to have the support custom LINQ provider like c# LinqToSql, LinqToXML, etc... [2011-02-28 21:23:54] dave dot mulford at gmail dot com Description: Having a php native LINQ-style of querying objects in PHP would make code more maintainable and readable. As of now, developers must loop through an array of objects and perform manual filtering, grouping, etc. Here is a link to Microsoft's examples of using LINQ: http://msdn.microsoft.com/en-us/vcsharp/aa336746 -- Edit this bug report at https://bugs.php.net/bug.php?id=54123&edit=1
Bug #63663 [Opn->Ana]: str_word_count does not properly handle non-latin characters
Edit report at https://bugs.php.net/bug.php?id=63663&edit=1 ID: 63663 Updated by: ahar...@php.net Reported by:kobrien at kiva dot org Summary:str_word_count does not properly handle non-latin characters -Status: Open +Status: Analyzed Type: Bug Package:Strings related Operating System: Ubuntu 12.04 PHP Version:5.3.20-dev Block user comment: N Private report: N New Comment: This is due to the use of isalpha() internally, which doesn't play well with multibyte encodings like UTF-8, regardless of the locale setting. Fundamentally, this is the same issue as bug #27668 â I'm not sure there's a lot we can do about this in PHP 5.x, but it's worth noting if and when we revisit Unicode string handling internally. Previous Comments: [2012-12-01 02:29:17] kobrien at kiva dot org Description: The function str_word_count() does work properly on non-latin characters. It will return a value of zero. Whereas str_word_count() works properly on latin characters and returns the value for the number of words in a string. Test script: --- https://bugs.php.net/bug.php?id=63663&edit=1
Bug #63663 [Ana]: str_word_count does not properly handle non-latin characters
Edit report at https://bugs.php.net/bug.php?id=63663&edit=1 ID: 63663 User updated by:kobrien at kiva dot org Reported by:kobrien at kiva dot org Summary:str_word_count does not properly handle non-latin characters Status: Analyzed Type: Bug Package:Strings related Operating System: Ubuntu 12.04 PHP Version:5.3.20-dev Block user comment: N Private report: N New Comment: Thanks for the reply. Given your comments about the problems, would it be helpful for me to also file a feature request for newer versions of php to have a mb_str_word_count function which could properly handle this case? I haven't dug into the C code enough to understand why isalpha() fails on multibyte, but I'd have to imagine there is an alternative available that will handle multi-byte characters properly. I could potentially even create a patch if pointed in the right direction. Previous Comments: [2012-12-03 02:29:16] ahar...@php.net This is due to the use of isalpha() internally, which doesn't play well with multibyte encodings like UTF-8, regardless of the locale setting. Fundamentally, this is the same issue as bug #27668 â I'm not sure there's a lot we can do about this in PHP 5.x, but it's worth noting if and when we revisit Unicode string handling internally. [2012-12-01 02:29:17] kobrien at kiva dot org Description: The function str_word_count() does work properly on non-latin characters. It will return a value of zero. Whereas str_word_count() works properly on latin characters and returns the value for the number of words in a string. Test script: --- https://bugs.php.net/bug.php?id=63663&edit=1
Bug #63663 [Ana]: str_word_count does not properly handle non-latin characters
Edit report at https://bugs.php.net/bug.php?id=63663&edit=1 ID: 63663 Updated by: ahar...@php.net Reported by:kobrien at kiva dot org Summary:str_word_count does not properly handle non-latin characters Status: Analyzed Type: Bug Package:Strings related Operating System: Ubuntu 12.04 PHP Version:5.3.20-dev Block user comment: N Private report: N New Comment: Yeah, a feature request for mb_str_word_count() might be a good idea. The isalpha() issue isn't really PHP specific: the underlying C function simply takes a single byte as its input, so it can't ascertain whether a multibyte character is actually alphanumeric or not (since it only ever gets the first byte of the sequence). There's an iswalpha() function that would do the right thing, but PHP was written before it was widely available, and using it in str_word_count() alone would be inconsistent with the rest of the language: it's something we'd need to think about as part of making the whole language more multibyte-aware. Previous Comments: [2012-12-03 02:36:37] kobrien at kiva dot org Thanks for the reply. Given your comments about the problems, would it be helpful for me to also file a feature request for newer versions of php to have a mb_str_word_count function which could properly handle this case? I haven't dug into the C code enough to understand why isalpha() fails on multibyte, but I'd have to imagine there is an alternative available that will handle multi-byte characters properly. I could potentially even create a patch if pointed in the right direction. [2012-12-03 02:29:16] ahar...@php.net This is due to the use of isalpha() internally, which doesn't play well with multibyte encodings like UTF-8, regardless of the locale setting. Fundamentally, this is the same issue as bug #27668 â I'm not sure there's a lot we can do about this in PHP 5.x, but it's worth noting if and when we revisit Unicode string handling internally. [2012-12-01 02:29:17] kobrien at kiva dot org Description: The function str_word_count() does work properly on non-latin characters. It will return a value of zero. Whereas str_word_count() works properly on latin characters and returns the value for the number of words in a string. Test script: --- https://bugs.php.net/bug.php?id=63663&edit=1
[PHP-BUG] Req #63671 [NEW]: Create a mb_str_word_count() function which is multi-byte aware
From: kobrien at kiva dot org
Operating system: Ubuntu 12.04
PHP version: 5.5.0alpha1
Package: *Unicode Issues
Bug Type: Feature/Change Request
Bug description:Create a mb_str_word_count() function which is multi-byte aware
Description:
Create a mb_str_word_count() function which will properly handle counting
the
number of words in string that contains multi-byte characters. This is
currently
not possible with str_word_count() because of use of the isalpha() C
function
which does not properly handle multi-byte characters.
As suggested by aharvey, this new function would replace usage of isalpha()
with
iswalpha().
A naive (meaning no real knowledge of this or testing of it) patch would
look
like:
diff --git a/ext/standard/string.c b/ext/standard/string.c
index 7a4ae2e..9ab6b5f 100644
--- a/ext/standard/string.c
+++ b/ext/standard/string.c
@@ -5202,7 +5202,7 @@ PHP_FUNCTION(str_word_count)
while (p < e) {
s = p;
- while (p < e && (isalpha((unsigned char)*p) || (char_list
&&
ch[(unsigned char)*p]) || *p == '\'' || *p == '-')) {
+ while (p < e && (iswalpha((unsigned char)*p) || (char_list
&&
ch[(unsigned char)*p]) || *p == '\'' || *p == '-')) {
p++;
}
if (p > s) {
Test script:
---
https://bugs.php.net/bug.php?id=63671&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63671&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63671&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63671&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63671&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63671&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63671&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63671&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63671&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63671&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63671&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63671&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63671&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63671&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63671&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63671&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63671&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63671&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63671&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63671&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63671&r=mysqlcfg
Bug #63663 [Ana]: str_word_count does not properly handle non-latin characters
Edit report at https://bugs.php.net/bug.php?id=63663&edit=1 ID: 63663 User updated by:kobrien at kiva dot org Reported by:kobrien at kiva dot org Summary:str_word_count does not properly handle non-latin characters Status: Analyzed Type: Bug Package:Strings related Operating System: Ubuntu 12.04 PHP Version:5.3.20-dev Block user comment: N Private report: N New Comment: Ok feature request filed here: https://bugs.php.net/bug.php?id=63671 First time doing that, so hopefully it's correctly filed. Previous Comments: [2012-12-03 02:47:28] ahar...@php.net Yeah, a feature request for mb_str_word_count() might be a good idea. The isalpha() issue isn't really PHP specific: the underlying C function simply takes a single byte as its input, so it can't ascertain whether a multibyte character is actually alphanumeric or not (since it only ever gets the first byte of the sequence). There's an iswalpha() function that would do the right thing, but PHP was written before it was widely available, and using it in str_word_count() alone would be inconsistent with the rest of the language: it's something we'd need to think about as part of making the whole language more multibyte-aware. [2012-12-03 02:36:37] kobrien at kiva dot org Thanks for the reply. Given your comments about the problems, would it be helpful for me to also file a feature request for newer versions of php to have a mb_str_word_count function which could properly handle this case? I haven't dug into the C code enough to understand why isalpha() fails on multibyte, but I'd have to imagine there is an alternative available that will handle multi-byte characters properly. I could potentially even create a patch if pointed in the right direction. [2012-12-03 02:29:16] ahar...@php.net This is due to the use of isalpha() internally, which doesn't play well with multibyte encodings like UTF-8, regardless of the locale setting. Fundamentally, this is the same issue as bug #27668 â I'm not sure there's a lot we can do about this in PHP 5.x, but it's worth noting if and when we revisit Unicode string handling internally. [2012-12-01 02:29:17] kobrien at kiva dot org Description: The function str_word_count() does work properly on non-latin characters. It will return a value of zero. Whereas str_word_count() works properly on latin characters and returns the value for the number of words in a string. Test script: --- https://bugs.php.net/bug.php?id=63663&edit=1
Req #54243 [Com]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243&edit=1
ID: 54243
Comment by: id2639730 at gmail dot com
Reported by:anil at saog dot net
Summary:Shorter syntax for closures
Status: Suspended
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
When do you plan to implement short syntax for closures?
+1 for c# lambda style.
Ecmascript 6 short function syntax used this approach. Typescript language
already using lambdas.
Zend Framework 2 and Symfony2 actively using closures to work with events.
Previous Comments:
[2012-04-11 14:55:49] johan...@php.net
One of the goals of PHP is to have a "verbose enough" syntax. Giving people
ways to search for information if they don't understand it. With the current
syntax people reading the code see the word "function" an can get an idea what
this might be and have a term to put in a search engine.
On the other side sometimes that is changed, like with arrays, initially one
had to use array() to build arrays, nowadays we have the $a = [ ]; as shortcut,
so maybe we'll add a new syntax, but only in the long run, when we see that
anonymous functions really are going mainstream.
[2012-04-11 09:38:34] ninzya at inbox dot lv
I'm sorry, Anil, but you did not convince me on readability of "Where($($a, $b,
{$a == $b}))".
"Microsoft's way" to define closures in C# linq "Where((a,b) => a == b)", in my
opinion, is far more readable. I read it as "a two argument function "(a,b)"
which results ("=>") in a being equal b ("a == b") or whatever the logic is
defined there. However you can not read "$($a, $b, {$a == $b})" as good as you
read microsoft's code. To me, there are too much dollar characters and they
make
your eyes hurt when you try to really understand which token does the dollar
sing really belong to. You definately don't want readers of your code to
tokenize a lot when the goal is readability :-)
[2012-03-19 11:54:13] anil at saog dot net
Guys, please calm down. I have no idea why you write these comments in a heat
but this issue is just a wishing. Also, readability is a non-objective property
which generally differs person to person, but the "key" is "shorter means
readable". By the way, did you ever inspect c# - linq syntax?
C# : ...Where((a,b) => a == b)
PHP : ...Where(function($a, $b){ return $a == $b; })
MY : ...Where($($a, $b, {$a == $b}))
readability? yes of course readability... so you think you are better than
microsoft on readability?
If you do not agree of course it is okay just tell it (like a human) otherwise
keep your ignoble and invaluable ideas to yourself.
[2012-03-19 11:13:20] ninzya at inbox dot lv
I think the proposed syntax is not readable at all. Rather it looks like you
have
been affected by a "wannabe jQuery inventor". How do you come up with a dollar
sign being "readable"? How do you define "readable code"? If you read your
code,
you read it as "dollar, dollar, bracket, dollar, dollar... whatever, dollar".
Is
this what you call "readability"?
However I do agree that the "use()" clause of closures sometimes bloats the
code a
little bit, especially if the closure is importing a lot of variables from its
context.
[2012-03-19 09:08:09] danko at very dot lv
Um, no, *that* is unreadable. The original syntax can easily be made readable
if you do care:
$myObject->MyMethod(
'abc',
function ($a) use ($b) {
return $a == $b;
}
);
There you go. As readable as it gets - just add some newlines and tabs. On the
other hand, a soup of brackets and dollar signs can't be readable regardless of
formatting.
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=54243
--
Edit this bug report at https://bugs.php.net/bug.php?id=54243&edit=1
