From:             gabriel at helicoid dot net
Operating system: Any
PHP version:      4.3.11
PHP Bug Type:     Feature/Change Request
Bug description:  Scope Resolution Operator usage seems flawed

Description:
------------
I believe there is a flaw in how the scope resolution operator works.

You can use a variable containing the name of the method you want to call
on the right hand side of the operator, which works fine. However, if you
try to have the class name on the left hand side in a variable, you get a
parse error:

Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM

I dare say that having the class name in a variable is actually more
useful than having the method name in a variable. You can already have the
class name in a variable if you're using the 'new' keyword, as my example
code shows, so the operation of the scope resolution operator doesn't seem
very consistent with this, which it should be.

A work around would be to actually instantiate an object from the class,
as my example code shows, however I don't think this is a particularly
good solution to this problem. eval()ing a section of code with the class
name as a variable would also work, but again, I don't think this is a
good solution either.

I don't _think_ allowing the scope resolution operator to operate in this
manner would break any existing scripts either, but I may be wrong.

Reproduce code:
---------------
class TestOne {

        function testMethod($num)
        {
                echo "In testMethod - num is $num\n";
        }

}

$method = 'testMethod';
$class = 'TestOne';

TestOne::$method('3');

//$class::testMethod('3'); // This doesn't work, and I believe it should.

$obj =& new $class;
$obj->testMethod('4');

Expected result:
----------------
I expect $class::testMethod('3') to really evaluate to
TestOne::testMethod('3')

Actual result:
--------------
Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM

-- 
Edit bug report at http://bugs.php.net/?id=33396&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33396&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33396&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33396&r=trysnapshot51
Fixed in CVS:                http://bugs.php.net/fix.php?id=33396&r=fixedcvs
Fixed in release:            http://bugs.php.net/fix.php?id=33396&r=alreadyfixed
Need backtrace:              http://bugs.php.net/fix.php?id=33396&r=needtrace
Need Reproduce Script:       http://bugs.php.net/fix.php?id=33396&r=needscript
Try newer version:           http://bugs.php.net/fix.php?id=33396&r=oldversion
Not developer issue:         http://bugs.php.net/fix.php?id=33396&r=support
Expected behavior:           http://bugs.php.net/fix.php?id=33396&r=notwrong
Not enough info:             
http://bugs.php.net/fix.php?id=33396&r=notenoughinfo
Submitted twice:             
http://bugs.php.net/fix.php?id=33396&r=submittedtwice
register_globals:            http://bugs.php.net/fix.php?id=33396&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33396&r=php3
Daylight Savings:            http://bugs.php.net/fix.php?id=33396&r=dst
IIS Stability:               http://bugs.php.net/fix.php?id=33396&r=isapi
Install GNU Sed:             http://bugs.php.net/fix.php?id=33396&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33396&r=float
No Zend Extensions:          http://bugs.php.net/fix.php?id=33396&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33396&r=mysqlcfg

Reply via email to