Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13

Hi! > Could you check out my last mail about the unserialize stuff?: > http://news.php.net/php.internals/74947 Reading this message, I gather the situation is as follows: 1. Original fix banned O: unserialization of classes that have custom serializers. 2. The following fix allowed this behavior for user classes. 3. The second fix means that if the user class descends from internal class with serializer, we still have a problem. My opinion is this: 1. Using unserialize() on anything that is not a result of serialize() is a hack. As such, there are no support guarantees that it would work in any particular manner, besides continuity of support for serialized format itself. In particular, we have no guarantees that string that did not come from serializer would behave in any particular way. 2. We should make reasonable effort to keep code that worked in version x.y.z working in x.y.z+1. However, "reasonable" is important here, if there's a behavior that is not documented and not wanted, we can break it. We don't have to and will try not to, but we can. 3. In light of this, I think we could do with current patch in 5.4 and 5.5 (one that permits userland classes) but we should plug it completely for 5.6. If somebody needs code that does whatever it did, it should be in Reflection or someplace else, serializer should do serializing. But I think for stable version it is a reasonable, if imperfect, compromise - it would allow most common use cases (userland classes) to work and most common crashes (internal classes) to not crash. Extending SplFileInfo looks a bit more exotic so I think we can live with it not being fixed till 5.6. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227