Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55919
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Cc: "Etienne Kneuss" <colder@php.net>
In-Reply-To: <CAEZPtU73tt_V4PKeevX5N3DCxo-r7bUnC1tEc+peaDc+uoMSVg@mail.gmail.com>
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
References: <CAEZPtU73tt_V4PKeevX5N3DCxo-r7bUnC1tEc+peaDc+uoMSVg@mail.gmail.com>
To: internals@lists.php.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date: Mon, 24 Oct 2011 15:13:21 +0100
Message-ID: <op.v3u0gjv3idpuyk@clk-0081.mshome.net>
User-Agent: Opera Mail/11.51 (Win32)
Subject: Re: [PHP-DEV] BC break in 5.4, extending internal class
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

Em Mon, 24 Oct 2011 14:53:07 +0100, Pierre Joye <pierre.php@gmail.com>
escreveu:

> https://bugs.php.net/bug.php?id=55300
> and in some extend to https://bugs.php.net/bug.php?id=55175
>
> I tend to think that it could have a very bad impact on existing and
> will prevent many users to migrate easily to 5.4, or smoothly. I think
> we have to figure a fix for this problem while making it 100% BC with
> 5.3. I'd to discuss this problem before we go with the 1st RC.
>

(context: this is the problem of calling internal methods on objects that
were not properly constructed).

The change I did in 5.4 should be reverted and synced with 5.3 in the
short term because it doesn't work reliably (even not considering the BC
break) -- there are other methods for getting an invalid instance (the new
reflection method and unserialize, at least).

But even in 5.3, there are in SPL counter-measures that don't work
reliably, like making a check in get_method.

Last month, Etienne was exploring the possibilities for this problem, but
I don't think he got to any good solution. In the medium term, either
direct calls to zend_object_store_get_object are banned and every method
goes through a class-specific wrapper or we come up with a better solution
(the only think I came up with in the discussion last time was enforcing
the restriction on zend_do_fcall_common_helper/zend_call_function by
calling a validation callback stored in the class_entry every time an
internal method is to be called).


-- 
Gustavo Lopes