On Tue, Dec 10, 2019 at 12:03 PM Dennis Birkholz <p...@dennis.birkholz.biz>
wrote:
> Hi Nikita,
>
> On 06.12.19 11:29, Nikita Popov wrote:
> > Could you provide some context on why you think serialization support for
> > WeakMap is important? As weak maps are essentially caching structures,
> > serializing them doesn't seem particularly useful in the first place, but
> > when combined with the quite unintuitive behavior the serialization would
> > have, I feel that it is better to leave this to the user (same as
> > WeakReference).
>
> structures provided by the PHP core tend to be used in the wild. As PHP
> lacks a method to check whether a given object (and all other objects
> contained within it) can be serialized (without traversing the complete
> object graph), each new always-available data structure that is not
> serializable increases the risk to encounter an object that is not
> serializable. That is the reason I prefer new data structures to be
> serializable.
>
> What I see coming is something like this: some kind of object that can
> contain other object and attach some meta information to that objects
> (that is stored as the value in a weak map). When an object is removed
> from the collection, the meta information gets removed eventually, no
> need to manually clear it in the remove-object method. If there are many
> different kinds of meta information this would save a lot of code in the
> remove method! Even though this seems to not be the intended use case,
> programmers tend to safe some key strokes here and there. That type of
> container object is not serializable unless the programmer takes extra
> steps and implements serialization him/herself.
>
> > Specifically what I mean by uninituitive is this: When you do a $s =
> > serialize($weakMap), you'll get back a large payload string, but when you
> > then try to do an unserialize($s) you'll get back an empty WeakMap (or
> > worse: a weak map that will only become empty on the next GC), because
> all
> > of those objects will get removed as soon as unserialization is
> finalized.
> > That "works", but doesn't seem terribly useful and is likely doing to be
> a
> > wtf moment.
>
> Ok, my intention was to have a more sophisticated approach: when the
> WeakMap is serialized, only objects in the object graph that is
> serialized are considered alive, all other objects are not serialized.
> So directly serializing a WeakMap would result in an empty map but
> serializing an object that contains a list of objects and a WeakMap
> containing some of the same child objects would create a meaningful
> payload string and unserialize would reconstruct the same object with
> only objects from the child list available in the WeakMap any more.
>
> I understand that this may complicate the implementation a lot (or even
> be not possible).
This is indeed not possible. When we serialize the WeakMap, we do not know
what else will be serialized as well. We can only serialize everything and
let unserialization discard objects that are no longer live.
> But my just want to repeat my main concern: buildin
> data structures that are not serializable are a real problem for users
> that use serialization extensively. Maybe the solution to that problem
> is a method to check whether a provided object graph can be serialized
> (which may not be possible due to throwing an exception in __sleep() or
> something like that), some way to ignore unserializable elements or some
> way to register callback methods to handle unserializable elements.
>
I'm must be missing something obvious here: Isn't this a reliable way to
detect whether an object graph is serializable?
try {
$serialized = serialize($value);
} catch (\Throwable $e) {
// not serializable
}
Nikita
