Overloading Clarifications for Manual

Hello Daniel,

Saturday, April 5, 2008, 3:27:33 PM, you wrote:

[Hmm... No answer in several days. Let's try this again with a
different subject]

I'm in the middle of clarifying the Overloading section of the manual,
http://docs.php.net/manual/en/language.oop5.overloading.php. Some issues
and questions have come up and your insights will be helpful, please.

• The docs say "All overloading methods must be defined as public." At
  this point (in 5.2.1 and 5.3.0 snapshot) all visibility declarations are
  ignored:

class bug_43924 {
    private function __call($name, $arguments) {
        echo $name . "\n";
    }
}

$obj = new bug_43924;
$obj->ObjectContext();

Is this an oversight in the engine? Are there plans to have the parser
enforce the public declaration?

We experimented with visibility and ran into trouble.

And just to confirm this:
[marcus@zaphod PHP_5_3]$ php -r 'class T{public function __call($n, $a){var_dump($n);}} $o=new T; $o->foo(); ReflectionMethod::export("T","__call");'
make: `sapi/cli/php' is up to date.
string(3) "foo"
Method [ <user> public method __call ] {
@@ Command line code 1 - 1

• Parameters [2] {
  Parameter #0 [ <required> $n ]
  Parameter #1 [ <required> $a ]
  }
  }

[marcus@zaphod PHP_5_3]$ php -r 'class T{protected function __call($n, $a){var_dump($n);}} $o=new T; $o->foo(); ReflectionMethod::export("T","__call");'
make: `sapi/cli/php' is up to date.
string(3) "foo"
Method [ <user> protected method __call ] {
@@ Command line code 1 - 1

• Parameters [2] {
  Parameter #0 [ <required> $n ]
  Parameter #1 [ <required> $a ]
  }
  }

So we in fact note the visibility but then ignore it.

I think we either need to respect the visibility or issue an error if it
is not public. Please file a but report.

• Along these lines, it would be an interesting new feature if one could
  declare any visibility for the overloading methods and have the engine
  observe them. This could allow people to use overloading for internal
  calls but skip them for external calls.

As said there were issues with this approach. Issues as in it wouldn't be
working as expected under all circumstances. So making ti possible would
eventually only increase the WTF factor.

• Some user comments say they find it helpful to have their __get()
  methods return by reference. Doing so is allowed at this point. Is this
  kosher? Will it remain so?

I think it is a bug. But iirc it was designed to either allow &__get() or
__get() for all derived classes. Does anyone remember?

• The value of $name in __call() is case sensitive, but in the newly
  added __callStatic() $name is lower case. Is this intentional? It seems
  the two methods should have the same behavior.

It isn't for function calls so this is the correct behavior.

• The new __callStatic() is neat. Thanks. Is there consideration of
  adding Static versions of the other overloading methods?

Sara maybe?

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

Best regards,
Marcus

Hi Daniel,

• The new __callStatic() is neat. Thanks. Is there consideration of
  adding Static versions of the other overloading methods?

It is part of the proposal for real static classes
(http://wiki.php.net/rfc/static-classes) to complete them accordingly
with __setStatic(), __getStatic() and so on. However this feature could
be implemented separatly.

cu, Lars