On Fri, 2013-07-26 at 11:58 +0100, Jakub Zelenka wrote: > > > > So rather change the engine, which affects way more things and add yet > > another serialisation hook making it even more confusing what to use? > > > > > > > Yes I agree that the new hook is confusing. I think that what Gustavo said > would be actually much better. Having some flag that would say what is > the purpose of retrieving properties could be very useful. It's not just > serialization > but also casting object to array. There can be even more use cases > in the future. On top of it the hooks like get_gc and get_debug_info > could be part of it. But I would rather discuss this leter > when I send a patch.
This means one has to touch every extension using those hooks. "more use cases in the future" means having to do this over and over again, for a feature I see little benefit in. Serializable was added precisely for the purpose to allow arbitrary internal classes to provide serializer logic. > > > > > > You're solution also depends on an API break and also changes the way > > the objects behave during serialization/unserialization. > > > > > Not sure what you mean by API break Breaking PHP's API. Requiring modifications to other extensions. > and changing the way the objects > behave? When you look to this pach > https://github.com/bukka/php-src/compare/date_serialize there shouldn't be > any difference in object behaviour. Or am I wrong? I haven't looked deeper but isn't your whole point to change the serialized representation of the object, to include all data "properly"? > By BC I meant the resulted string that you get after using serialize > function. If you use Serializable you get something that is prefixed by C: > . But if you have object, the prefix is O: . Please see this > http://3v4l.org/Sd8aT . I know the difference. So yes, new serialized files can't be properly read on old PHP. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
