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: [EMAIL PROTECTED] 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 ] } } [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
