Re: New handler for retrieving properties when object is serialized
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 break too many
> extensions. The idea is to create something like
>
> HashTable *get_special_properties(zval *object, int purpose, int *is_tmp
> TSRMLS_DC)
>
> This would replace get_debug_info so the number of hooks would stay the
> same.
> The only extensions that would need to be changed are the ones that use
> get_debug_info. The purposes could be debug, serialize, array_casting. If
> there is a new use case, you would just add new purpose and wouldn't have to change
> anything.
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 there is a
change.(a tiny bit better would be using an enum instead of int as in
some situations compilers/analyzers might give a hint ... but still a
mess)
But I still don't buy the argument for this hook.
Typically internal classes use some C data structure for keeping their
internal state. Often actually in a form that it can not be represented
in zval. From that observation (after a few years of looking at phpsrc,
pecl external and close-source exts) Serializable is the preferred way
to serialize these in an efficient way (converting everything in zvals,
then serialize, finally freeing temporary data is a quite expensive
way ..)
(mind: comparison with debug hooks is only of limited use. a) a debug
feature has less performance relevance b) a debug feature doesn't need
to convert the full state and has no need to be reversible)
So what is being proposed is to extend our already too large API with
yet another way of doing something for edge cases for which we have a
good solution for the general case already.
> > I haven't looked deeper but isn't your whole point to change the
> > serialized representation of the object, to include all data "properly"?
> >
> >
> No the whole point was returning the same properties but only if the object
> is serialized or debugged. Deeper explanation is in this thread:
So the purpose is to have a different serialized representation, so
there would be compatibility issues, similar to going to Serializable.
johannes
Thread (22 messages)