Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85983
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender)
Message-ID: <553F1B0F.8070303@gmail.com>
Date: Mon, 27 Apr 2015 22:30:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Julien Pauli <jpauli@php.net>
CC: Andrew Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
References: <CAMUwpuTZK=zqHcWG21DA5fUSODuq6njyx9+RUtQR0gQu02a5AQ@mail.gmail.com> <55342A50.9030100@gmail.com> <CAMUwpuQUFa0G5wB=Bz_KJEDVOkCpaAEAfonHgQEh_MnzwhA-sA@mail.gmail.com>
In-Reply-To: <CAMUwpuQUFa0G5wB=Bz_KJEDVOkCpaAEAfonHgQEh_MnzwhA-sA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Closure::call() to access private data, really ?
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Perhaps the best thing to do is to forbid rebinding a Closure to an
> internal class ?

So I have checked into this further, and the good news is that we don't
have too many internal classes that declare private/protected
properties. Actually, the only one where you could mess stuff up was
Exception, and that seems to be recently fixed by adding typechecks for
(almost) unrelated unserialize issue. So for now, I do not see a lot of
ways to mess things up in core PHP. Of course, third-party extensions
may be different.

Still, I don't like the idea of rebinding to internal classes too much
(in fact, I'm not sure I like the whole rebinding thing as such in
general, but that's another story) so here's a pull that forbids this:

https://github.com/php/php-src/pull/1253

Please review and comment.
-- 
Stas Malyshev
smalyshev@gmail.com