Re: [PHP-DEV] New handler for retrieving properties when object is serialized
On 27 July 2013 15:58, Jakub Zelenka bu...@php.net wrote: Alternatively, could the problem perhaps be mitigated by making available some utility functions for serializing native types? We could definitely make some parts of serializer API-accessible, or even make serializer as a whole to be more API-friendly, I think it'd be a nice idea if making implementing Serializable would be made easy by reusing serializer code and combining pieces. If now it's hard making it easier definitely a good idea, much better than creating one more API IMHO. I was thinking about that and it could actually be done in a way that would resolve the problem. I have just created RFC that specify the API. https://wiki.php.net/rfc/internal_serialize_api It's backward compatible and allow portable object generation in more abstract way. What's about unserialization? Where does the state come from when recursively calling serialize? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Constification of some PHP API calls
On Mon, Jul 29, 2013 at 12:01 PM, Andrey Hristov p...@hristov.com wrote: Hi, after experiencing again warnings about conversion from const char * to char * when calling some PHP API functions I decided to spend some time and constify a few of these. The result is a patch that constifies the Streams API, and few functions in Zend and TSRM (to which I have no karma). Most of the changes are conversion of char * to const char * parameters, where applicable. In a few places string lengths are changed from int to size_t. Few functions return now const char * instead of char * (the caller did not modify/release these before). The patch is against php-src because it changes API which can be only done in a new version. Opinions? I'm +1. About strings sizes from int to size_t , you perhaps could sync with Anthony who worked hard recently on such changes, especially regarding zval string type. Julien.Pauli
Re: [PHP-DEV] New handler for retrieving properties when object is serialized
Hi What's about unserialization? Yeah that's actually a good point! :) It could be handled by implicit object unserialization if the unserialize callback is NULL. However this is not optimal for performance and also create properties in the object which doesn't have to be necessary. There should be functions that help with parsing the string buffer that is passed to unserialize class callback. Sort of opposite to API for serialization. It should be part of RFC. I will add it. Where does the state come from when recursively calling serialize? I am not sure if I understand the question. The serialize_state will be a sort of wrapper for smart_str with some additions for checking whether the functions are called in correct order. The state instance will be in most cases a local variable (as it is in the example). In case you try to serialize object zval (using php_serailize_property_zval), it would try to serialize the object the same way and the resulted string would be added to the state buffer (will be in RFC...). Did I answer your question? I will try to clarify the RFC a bit. Any feedback would be much appreciated. Thanks. Jakub
