Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49967
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain giacobbi.net from 95.110.130.42 cause and error)
Date: Mon, 25 Oct 2010 01:23:02 +0200
To: Etienne Kneuss <colder@php.net>
Cc: internals@lists.php.net
Message-ID: <20101024232302.GD19835@gerbil.thgnet.it>
References: <20101024223825.GC19835@gerbil.thgnet.it> <4CC4B628.3060304@sugarcrm.com> <20101024225628.GB88594@croustillant.local> <20101024230400.GC88594@croustillant.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20101024230400.GC88594@croustillant.local>
User-Agent: Mutt/1.4.2.2i
Subject: Re: [PHP-DEV] BC break in 5.3.2 -> 5.3.3 with "parent::" and __call/__callStatic
From: giovanni@giacobbi.net (Giovanni Giacobbi)

On Mon, Oct 25, 2010 at 01:04:00AM +0200, Etienne Kneuss wrote:
> On Oct 25  0:56:28, Etienne Kneuss wrote:
> > > 
> > > I think you meant Bar to extend ActiveRecord? But anyway, I think
> > > that this particular call should be done through __call, not
> > > __callStatic, since it's basically non-static call. The line between
> > > the two wasn't really well-defined in PHP (you could call static
> > > methods non-statically and vice versa) which is a pity but I think
> > > distinction can be made in this case.
> > 
> > Exactly, if Bar::getFoo is not called statically, parent::getFoo() will
> > not be a static call, it should not get through __callStatic.
> > 
> > Best,
> 
> Oh, and #51176 seems bogus to me. "::" is not sufficient to indicate a
> static call, neither is "self::", "static::", or "Foo::".
> 
> A call is only static if one of the two following conditions match:
>     1) the target method is declared as static
>     2) the call comes from an object-less scope
> 

I think you perfectly got the point. However, being actually non-defined, we need to choose between __call() and __callStatic(), and i think that number 2 is the only applicable criteria.

Note that for my problem, reverting commit 295706 in branch PHP_5_3 is enough to fix my problem, but it would break again 51176.

As this is a BC break compared to the 5.3.x series, IMHO it's the right way to go and then find another solution for 51176.

-- 
Giovanni Giacobbi