Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53C7821F.8040301@sugarcrm.com>
References: <CABBJUpf4Zrj+MiqGoUPp6NWBBpJzntu0NAyveZyrqx0oNQYpBA@mail.gmail.com>
 <53C75A89.5000401@fedoraproject.org> <CABBJUpfeDv1juoL=1bkaiY3M9cgLd8f6NMagSqccoQVC+vekCw@mail.gmail.com>
 <53C7685B.3040302@sugarcrm.com> <248a94f0ee70cf99ffbb0f204443ebbf@mail.gmail.com>
 <53C7709D.5060208@sugarcrm.com> <CADyq6sLCiZh98E8RXDvPo20ak7H7Wb5EFsQ4MvMa3UfapV8bqw@mail.gmail.com>
 <53C7821F.8040301@sugarcrm.com>
Date: Thu, 17 Jul 2014 10:22:42 +0200
Message-ID: <CADyq6sK=PU2D38LiO1E88KtWVWPuujwJQCymDNN8UAZ=w_11yg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Zeev Suraski <zeev@zend.com>, Laruence <laruence@php.net>, 
	Remi Collet <remi@fedoraproject.org>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bf0cad468721804fe5f593c
Subject: Re: [PHP-DEV] An BC issue in unserialize
From: ocramius@gmail.com (Marco Pivetta)

--047d7bf0cad468721804fe5f593c
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 17, 2014 at 9:58 AM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > As discussed in previous threads about this failure, we (doctrine) can
> > move away from the `unserialize()` hack if
> > `ReflectionClass#newInstanceWithoutConstructor()` provides support for
> > internal classes.
>
> Could you explain why it is needed to instantiate internal classes
> without calling the ctor? I'd like to understand the use case more.
>

I honestly don't have a use-case for it myself, and I also strongly
disagree with extending internal PHP classes due to their fragility.
What I know is that many Doctrine users extend `ArrayObject` in entities,
which is what caused us to apply a hotfix only for 5.4.29 and 5.5.13, and
NOT 5.6.0.


> > It doesn't need to cover ALL internal classes, just the most commonly
> > extended ones.
>
> The problem is we do not know which of these classes may fail if
> instantiated without initializing. With PHP classes, it's easy since the
> engine takes care of the basic plumbing. With C classes, if you don't
> call the function, you get nulls or worse, garbage, in places where
> values are expected.


Yes, that indeed.
What I am suggesting is to provide a small map of internal PHP classes that
are supported by `ReflectionClass#newInstanceWithoutConstructor()`, so that
their internal data can be initialized even if the userland constructor is
not invoked.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--047d7bf0cad468721804fe5f593c--