Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113106 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 43274 invoked from network); 8 Feb 2021 09:53:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Feb 2021 09:53:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C02EE180539 for ; Mon, 8 Feb 2021 01:38:10 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 8 Feb 2021 01:38:07 -0800 (PST) Received: by mail-il1-f173.google.com with SMTP id y5so12133052ilg.4 for ; Mon, 08 Feb 2021 01:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DtXP1sKw9YfcnyPHjUu7CtUKW+3A1jz5mwnQCMfQ3BA=; b=AxkPyMMvbo7rLxbx8ub0QBwFGx25p0eM3Nt/c2iDTEH18mDDMTy14E8j5rLVGJpvZc jNPYmjRvHCxvrtxAde37mlBR0Dt7eiXNEt8DcvTz2/Cew6QSv895C1xbupLP4U4J90yI CCLwCibqn5xAnDmMC4jnKylpxIhlhEAvp5mqQRezghZm8JjXQXEmuhaQv+rsPL8Qjqlc IMlVo496xYEPWA1KLPddtdnz1t8l4PLl2wo3RuXeyunzEVUyYVlcUAMLjGcIrcvar7Nc c1XPw2nqtzyHr15Dw/C88Dxei9uYDzizjtBQ4SXwDeL5RqK/3Ig16IsSthuaGHuIEenp sEgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DtXP1sKw9YfcnyPHjUu7CtUKW+3A1jz5mwnQCMfQ3BA=; b=IpFVY4zZoIobLJ6VN9Y2JwmuXf4sVTXbn3pNJjgE7m0Z/kLdBy5OchC/oow/7OsBCP JSUvBE0TL4CgBOW//DvhldP0DszFm551lnLywdUv7iMSDvv5lV73gMolF/ZDtMChX93e y8g9orJbfRKFL2vARWZ8OKcbRd9/+jnsqTOQOGJfj8prezkDSBOPJW855c8k5T3s3ADY dp7g1WL0gYOP/wtFiN2aC/zCgjZrC3oHVghXyWKDjfkfS5nl032x9nIVbBlqBTbizJuG mn7CRQ2QSGB9gZ3SnPBjp9TPMIH6al2CdagclETQTU+dzjExdXfsdSo1fdAYXZ5TquZB v/zQ== X-Gm-Message-State: AOAM530exBrtepamkXX42TgdPUn2Chu10k/p1MhBRqUfDwpho93njQ42 EgAd7W1vxpPKUpKmfRl2KG6aTqec86o= X-Google-Smtp-Source: ABdhPJw/4ep6Rg+nQHT2uAO+EpfvjGK4CIgikjjhBnp7N5cBygx173LGqRZDyNJ/GPN/JehhD0lv0w== X-Received: by 2002:a05:6e02:152c:: with SMTP id i12mr13920042ilu.46.1612777086285; Mon, 08 Feb 2021 01:38:06 -0800 (PST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id c6sm8780737ioc.26.2021.02.08.01.38.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 01:38:05 -0800 (PST) Received: by mail-io1-f51.google.com with SMTP id n201so14207703iod.12 for ; Mon, 08 Feb 2021 01:38:04 -0800 (PST) X-Received: by 2002:a6b:7e49:: with SMTP id k9mr14360697ioq.181.1612777084746; Mon, 08 Feb 2021 01:38:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 8 Feb 2021 09:37:29 +0000 X-Gmail-Original-Message-ID: Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="0000000000003d086b05bacfed60" Subject: Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a` From: phpmailinglists@gmail.com (Peter Bowyer) --0000000000003d086b05bacfed60 Content-Type: text/plain; charset="UTF-8" On Mon, 1 Feb 2021 at 15:40, Bob Weinand wrote: > My main concern in this iteration of the RFC is: what happens with > big/deeply nested objects? > They tend to spew tons of lines if var_dump()'ed. Do we have reasonable > depth/output limitations in default dumping mode? > Good catch Bob, I'd completely overlooked this was missing in the RFC. I like how IPython's REPL has configuration options for this. When I start it I can pass in arguments to truncate the output a lot or not at all. If I always want these settings, I add them to a config file. I hoped existing REPLs (in different languages) would have consensus about when and where to truncate output, and representations to use; but when I played with a few over the weekend, there wasn't. Some assume you want everything output; others (for data structures) the first N items, and others the first N/2 and the last N/2. Objects often show very little that's useful. Do you know of any research or writeups as to what works best - or even saved output of how various REPLs show their output? Peter --0000000000003d086b05bacfed60--