Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107909 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76709 invoked from network); 10 Dec 2019 13:05:07 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 10 Dec 2019 13:05:07 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 0DB9B2C3218 for ; Tue, 10 Dec 2019 03:03:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 144.76.0.0/16 X-Spam-Virus: No Received: from mail01.nexxes.net (mail01.nexxes.net [144.76.185.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Tue, 10 Dec 2019 03:03:15 -0800 (PST) Received: from [192.168.0.193] (unknown [93.159.255.203]) (Authenticated sender: db220660-p0g-1) by mail01.nexxes.net (Postfix) with ESMTPSA id A509186054E; Tue, 10 Dec 2019 12:03:13 +0100 (CET) To: Nikita Popov Cc: PHP internals References: <1d2d5c23-3864-a202-92a8-34228798510d@birkholz.biz> Message-ID: Date: Tue, 10 Dec 2019 12:03:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Envelope-From: Subject: Re: [PHP-DEV] Re: [RFC] Add WeakMap From: php@dennis.birkholz.biz (Dennis Birkholz) 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). 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. Anyway, thanks for taking your time and for bringing this proposal forward! Greets Dennis