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
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
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
What about using our Serializable interface? - That was invented to
serialize internal objects with arbitrary internal data.
This is a bit painful to generate and then parse (unserialize) string if
you do it in C... Especially if you need only add few properties that will
contain data for
You can check for BG(serialize_lock) instead of GC_G(gc_active)
What if there was an extension that call php_var_serialize without locking?
I know there probably isn't any but still I don't think that this is a nice
way how to provide data for serialization.
What I think is that we should
On Fri, 2013-07-26 at 10:38 +0100, Jakub Zelenka wrote:
This is a bit painful to generate and then parse (unserialize) string
if you do it in C... Especially if you need only add few properties
that will contain data for serialization. In that case Serailizable is
a bit overkill...
So
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
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
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.
I don't want to change get_properties. That would break too many
extensions. The idea is to create something like
On Fri, 2013-07-26 at 14:14 +0100, Jakub Zelenka wrote:
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.
I don't want to change get_properties. That would
On Fri, Jul 26, 2013 at 2:59 PM, Johannes Schlüter
johan...@schlueters.dewrote:
Such a way for overloading is bad. This is painful on each update. If
there are different things to do use different hooks. The
implementations might call the same implementation but a purpose
option leads to a
Hi!
This is a bit painful to generate and then parse (unserialize) string if
you do it in C... Especially if you need only add few properties that
will contain data for serialization. In that case Serailizable is a bit
overkill...
And for my use case (DateTime serialization) it would be BC
On 26-07-2013 15:59, Johannes Schlüter wrote:
Such a way for overloading is bad. This is painful on each update. If
there are different things to do use different hooks. The
implementations might call the same implementation but a purpose
option leads to a long term maintenance hell whenever
On 26-07-2013 11:53, Jakub Zelenka wrote:
You can check for BG(serialize_lock) instead of GC_G(gc_active)
What if there was an extension that call php_var_serialize without locking?
I know there probably isn't any but still I don't think that this is a nice
way how to provide data for
Hi!
Yes, this would break extensions. But we never made any promises about
source BC for extensions. In fact, we actually break it for every
Actually, we try to preserve source BC for extensions, unless they do
some weird things or they go very deep into the implementation details.
Regular
Hi,
I have just sent this PR: https://github.com/php/php-src/pull/397
It's reaction to the comment from nikic in PR:
https://github.com/php/php-src/pull/393
The patch is about adding new object handler that is used when object is
serialized. Currently this needs to be done using get_properties
Hi!
It's useful in situation if you only need to change properties for
serialization. It's very similar to get_debug_info that is used only in
specific situations (print_r...)
Isn't __sleep already doing this?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
On Thu, Jul 25, 2013 at 9:09 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
It's useful in situation if you only need to change properties for
serialization. It's very similar to get_debug_info that is used only in
specific situations (print_r...)
Isn't __sleep already doing this?
Hi!
__sleep returns an array of object property *names* to be serialized.
Using __sleep you can restrict the set of serialized properties, but the
properties still need to exist.
You can create those properties when processing __sleep. Nothing
requires them to exist before __sleep was called.
On Thu, Jul 25, 2013 at 8:56 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
You can create those properties when processing __sleep. Nothing
requires them to exist before __sleep was called.
The problem is that properties will exist after __sleep was called. :)
There are situations that you
On 25-07-2013 18:42, Jakub Zelenka wrote:
I have just sent this PR: https://github.com/php/php-src/pull/397
It's reaction to the comment from nikic in PR:
https://github.com/php/php-src/pull/393
The patch is about adding new object handler that is used when object is
serialized. Currently
On Thu, 2013-07-25 at 21:01 +0100, Jakub Zelenka wrote:
On Thu, Jul 25, 2013 at 8:56 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
You can create those properties when processing __sleep. Nothing
requires them to exist before __sleep was called.
The problem is that properties will
22 matches
Mail list logo
