# Overloading Clarifications for Manual - Thread: https://externals.io/message/36813 - Original archive: https://news-web.php.net/php.internals/36813 - Started by Daniel Convissor on 2008-04-05T13:27:33+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #36813 — Daniel Convissor — 2008-04-05T13:27:33+00:00 URL: https://externals.io/message/36813#36813 [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? * 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. * 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? * 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. * The new __callStatic() is neat. Thanks. Is there consideration of adding Static versions of the other overloading methods? 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 --- ## #37857 — Marcus Boerger — 2008-05-25T08:57:22+00:00 URL: https://externals.io/message/36813#37857 · In reply to: #36813 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 [ public method __call ] { @@ Command line code 1 - 1 - Parameters [2] { Parameter #0 [ $n ] Parameter #1 [ $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 [ protected method __call ] { @@ Command line code 1 - 1 - Parameters [2] { Parameter #0 [ $n ] Parameter #1 [ $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 --- ## #37861 — Daniel Convissor — 2008-05-25T14:30:32+00:00 URL: https://externals.io/message/36813#37861 · In reply to: #37857 Hi Marcus: > Saturday, April 5, 2008, 3:27:33 PM, you wrote: > > We experimented with visibility and ran into trouble. ... > 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. Turns out, one already exists: http://bugs.php.net/bug.php?id=44769 > > […] > > It isn't for function calls so this is the correct behavior. I don't understand your response. Can you please clarify? 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 --- ## #37863 — Marcus Boerger — 2008-05-25T16:48:48+00:00 URL: https://externals.io/message/36813#37863 · In reply to: #37861 Hello Daniel, Sunday, May 25, 2008, 4:30:32 PM, you wrote: > Hi Marcus: > > > […] > ... > > […] > Turns out, one already exists: http://bugs.php.net/bug.php?id=44769 > > […] > I don't understand your response. Can you please clarify? Oh, actually it is my fault - I've read this part wrong. So infact __call is case sensitive. This is becasue the engine is indeed case sensitive up to the final lookup all over the place. We do that so that we can produce case sensitive error messages. So not doing a down case just enables the same behavior for the user. The other reason for making __call case sensitive is that an overloaded object might need the correct casing information. That said there is a bug in __callStatic which we need to report and assign to Sara. > --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 --- ## #37864 — Lars Strojny — 2008-05-25T17:07:01+00:00 URL: https://externals.io/message/36813#37864 · In reply to: #36813 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 --- ## #37875 — Daniel Convissor — 2008-05-26T00:35:10+00:00 URL: https://externals.io/message/36813#37875 · In reply to: #37864 Hi Lars: > > > > […] > > 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. Cool. It would be nice if the __*Static() magic methods could exist in regular classes, not just the proposed static classes. A question regarding this part of your RFC: Static classes may not have a constructor, destructor, dynamic interceptors or __toString() What do you mean by dynamic interceptors? 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 --- ## #37876 — Daniel Convissor — 2008-05-26T00:44:58+00:00 URL: https://externals.io/message/36813#37876 · In reply to: #37863 Hi Marcus (and Sara): > > That said there is a bug in __callStatic which we need to > report and assign to Sara. http://bugs.php.net/bug.php?id=45089 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 --- ## #37895 — Marcus Boerger — 2008-05-26T13:30:17+00:00 URL: https://externals.io/message/36813#37895 · In reply to: #37864 Hello Lars, Sunday, May 25, 2008, 7:07:01 PM, you wrote: > Hi Daniel, > > > […] > 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 I would like to have your proposal implemented with these restrictions: - No non static member whatsoever - No inheritance (autmoatically marked as final) - No abstract members (fonal classes cannot have abstract members) Best regards, Marcus --- ## #37898 — Lars Strojny — 2008-05-26T14:33:58+00:00 URL: https://externals.io/message/36813#37898 · In reply to: #37875 Hi, Am Sonntag, den 25.05.2008, 20:35 -0400 schrieb Daniel Convissor: [...] > What do you mean by dynamic interceptors? They might not have __get()/__set(), etc. pp. But at the end it is just a clarification as static classes might not have non-static members anyway. cu, Lars --- ## #37912 — Daniel Convissor — 2008-05-27T02:45:39+00:00 URL: https://externals.io/message/36813#37912 · In reply to: #37898 Hi Lars: > > They might not have __get()/__set(), etc. pp. But at the end it is just > a clarification as static classes might not have non-static members > anyway. Ah. May I encourage you to edit the RFC to explicitly name which methods will exist and be prohibited? 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 --- ## #37913 — Stanislav Malyshev — 2008-05-27T02:45:55+00:00 URL: https://externals.io/message/36813#37913 · In reply to: #37895 Hi! > I would like to have your proposal implemented with these restrictions: If we are going to discuss some RFC, isn't it better to have topic that at least mentions this RFC? Specific call for discussion would be nice too... -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #37915 — Lars Strojny — 2008-05-27T11:58:30+00:00 URL: https://externals.io/message/36813#37915 · In reply to: #37913 Hi Stas, Am Montag, den 26.05.2008, 21:45 -0500 schrieb Stanislav Malyshev: [...] > > […] > > If we are going to discuss some RFC, isn't it better to have topic that > at least mentions this RFC? Specific call for discussion would be nice > too... the proposal is not yet ready, so there can't be a decision or valuable discussion at this point. Please leave me some time to finish it :) Thanks, Lars --- ## #37920 — Stanislav Malyshev — 2008-05-27T18:30:22+00:00 URL: https://externals.io/message/36813#37920 · In reply to: #37915 Hi! > the proposal is not yet ready, so there can't be a decision or valuable > discussion at this point. Please leave me some time to finish it :) OK, no problem. I was just surprised it's being discussed, and yet in non-related topic :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com