Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:43318 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82317 invoked from network); 11 Mar 2009 21:56:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Mar 2009 21:56:43 -0000 Authentication-Results: pb1.pair.com header.from=truth@proposaltech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=truth@proposaltech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain proposaltech.com from 66.51.199.86 cause and error) X-PHP-List-Original-Sender: truth@proposaltech.com X-Host-Fingerprint: 66.51.199.86 exvs01.ex.dslextreme.net Windows 2000 SP4, XP SP1 Received: from [66.51.199.86] ([66.51.199.86:24445] helo=EXVS01.ex.dslextreme.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 20/5F-09289-99338B94 for ; Wed, 11 Mar 2009 16:56:42 -0500 Received: from 71.128.48.248 ([71.128.48.248]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Mar 2009 22:01:17 +0000 Received: from inspiron by owa.dslextreme.net; 11 Mar 2009 14:56:38 -0700 To: internals@lists.php.net In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 11 Mar 2009 14:56:37 -0700 Message-ID: <1236808598.6703.228.camel@inspiron.local> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Subject: Re: [PHP-DEV] non static function called as static one From: truth@proposaltech.com (Todd Ruth) On Wed, 2009-03-11 at 22:16 +0100, Olivier Doucet wrote: > Hello, > > I posted the same topic on the general mailing list, but it appears this can > be posted here, as it is open to feedbacks and is about PHP implementation > of static functions. > > I'm wondering if the following behaviour is a bug or a feature. The case is > quite complex, so let me explain my point of view. > here is the source : > > > class MyTest { > public function myfunc() { > echo get_class($this); > } > } > class MySecondTest { > public function test() { > MyTest::myfunc(); > } > } > > $test = new MySecondTest(); > $test->test(); //output: "MySecondTest" > > ?> > > In this case, $this is MySecondTest, which is relevant as it is the last > object context. But to my mind, this code should not work like this. > > Imagine you are the developer of function MyTest. You want your code to > interact with other classes and being bugproof. 'MyTest' class here seems > OK: $this is expected to be 'MyTest' because function myfunc() is expected > to be called in a non-static context. > > Programmer of the second function created this bug and this unattended > behaviour. > > Maybe this can be done : > 1/ Forbid calling the function in static context (How can I test this ? > $this is not NULL there !). > 2/ (or/and) Raise an error if a non static function is called as a static > one (if E_STRICT is set, strict warning is already raised). > 3/ Create two functions with the same name, one static and the other one > not. Unfortunately, this can't be done (yet ?). > > > What do you think ? What's your point of view on this ? I want your > feedbacks before opening a bug ticket, as it is not strictly a "bug"... Comments from a lurker... For better or worse, it's been well documented that what you are describing is php's behavior and it would be an enormous backwards compatibility break to change it. Consider the following example, in which two generally unrelated class heirarchies have enough in common somewhere in the tree that some would be inclined to use multiple inheritance: x); } } $example = new A; $example->x = 5; $example->f(); ?> Is that a messed up design? Almost certainly. Is it a nightmare to re-design/re-implement many tens of thousands of lines of code that rely on such behavior? Unfortunately, that's true also. (You may have guessed that I'm responsible for such code and most of it was written before I joined the company.) I like to think this rules out options 1 and 2. I'm not sure about option 3. Maybe there could be a function that returns whether the current function call is associated with the current object (ie whether it was called via :: or ->). I'm not an internals expert. Maybe to address backwards compatibility and address the concern you raise, there could be a "nonstatic" keyword. php would throw an error if a function declared "nonstatic" is called using ::. - Todd