Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71405 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15615 invoked from network); 22 Jan 2014 11:12:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jan 2014 11:12:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.160.54 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.160.54 mail-pb0-f54.google.com Received: from [209.85.160.54] ([209.85.160.54:37207] helo=mail-pb0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A2/60-13626-DA7AFD25 for ; Wed, 22 Jan 2014 06:12:45 -0500 Received: by mail-pb0-f54.google.com with SMTP id uo5so243470pbc.41 for ; Wed, 22 Jan 2014 03:12:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SSf9CPiMDLuaCxc1EhOYGYk/EvM3aG/3VkaZUVTOGJs=; b=DHPdeSbImMUZoQ6YAcV5xjjCkVrtrJEDmcGkhEH5v9+BsGevImYViytZlbgYC+upr6 z7yy/CJPBZUwZYFSSt+eCOux8FtMm1WcOu9Xjz6HU/Vb8LgaoEqwoD8uRu+Uxuq7iHBk shNS/OCyuPLUMOAj8QRbPyTWi3s57R3tlzWKcMOM0BaEhujM4aVPxhI6DU4ahc0uFjCQ sGj0vU4Kur/+UYZjmwtVRmRJUr7lUWmzkw8YbXJMQb0WPiPnbWSizhGPbNRz2XWdvZGb VR7riEkmJPbpVx0Y1qgbwUkY/cVX57EkizAIuNJr0MAoqcg5z5fyo6KTP0y1gw6y1AoF fnPg== X-Gm-Message-State: ALoCoQlscclHnFw6t9bj6jR2L2OFbYUj/xg6nKpDIrPPnZRGar14lEY6v1CaKKCbuNL7p++J6CcE MIME-Version: 1.0 X-Received: by 10.68.209.193 with SMTP id mo1mr1067629pbc.38.1390389162027; Wed, 22 Jan 2014 03:12:42 -0800 (PST) Sender: php@golemon.com Received: by 10.70.77.164 with HTTP; Wed, 22 Jan 2014 03:12:41 -0800 (PST) X-Originating-IP: [2001:470:1f09:2fa:22c9:d0ff:fe87:295b] In-Reply-To: References: <2D2D996C-9455-4DD1-9669-90AFAF591E32@strojny.net> Date: Wed, 22 Jan 2014 03:12:41 -0800 X-Google-Sender-Auth: XT8DcqsIr79c9uIkRaJjiVryj8o Message-ID: To: Pierre Joye Cc: Lars Strojny , PHP internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] [RFC] __debug_info() From: pollita@php.net (Sara Golemon) On Tue, Jan 21, 2014 at 9:46 PM, Pierre Joye wrote: > One additional comment, I am not sure about the manual merge of > properties. Maybe it should create an additional property called > "debugInfo" or something similar and store the result of __debugInfo > in it? It could be more user-friendly and less confusing. > Functionally speaking, the merge has to happen regardless since we can't just put temporary elements into the properties table and return that. Sure we could do the work for the user by putting the merge in the standard object handler, but what does it buy us? From my point of view, it buys us less options for the user. By returning the result of __debugInfo() as-is, the class author can replace, merge, or stuff debug into an extra prop at their discretion. By making a unilateral decision to merge, we exclude the option of not including certain props. By making the decision to put __debugInfo() result into a specific '__debug' prop, we take all the options away. Personally, I'm for giving power to the user here. (Not least because my use-case would quite like being able to control what's shown for var_dump()) -Sara