Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119021 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21309 invoked from network); 21 Nov 2022 15:48:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Nov 2022 15:48:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 331B9180503 for ; Mon, 21 Nov 2022 07:48:43 -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,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 21 Nov 2022 07:48:42 -0800 (PST) Received: by mail-wr1-f48.google.com with SMTP id x5so16409724wrt.7 for ; Mon, 21 Nov 2022 07:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=7nJrRKDDTfqJ4NICE8vNUoH2PIFIWXMqAb+qWXeMHe8=; b=Wbm4W/xsZ3rfcVknveCL4Ih1+9IlSoSkcJWolg4PBHUzTP9cgEPdi3DoMFETUh6EM/ bATb1a0wK0iJxsekB7BqcpYfTyY9hsJ8OLKXSv+f80vet14XEvLBGFq5GVRwzYh/Nm+N Y/+2kWDV9Y2xc4su4zs9vBWT/lbeULOpK1F2c8TtqePNNTcf3vksFlNGwOtTNEewtCk1 Zs71XefMgDovyAy7BDJ7FNJkIDwxBOAIF8z8dbK7Y1w0zMTAZ68bzCrw0H7WXsXb6zEz k4YaOKw9c7D5a3DgSpUEMR4zSkJ8rXnRmT3xWJ59XX8BNbMf4QrjCKcEiCI65JVVCVnw K/gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7nJrRKDDTfqJ4NICE8vNUoH2PIFIWXMqAb+qWXeMHe8=; b=gzjnvaoM8znnxR9fgx4Ao3RweZDwbG7sKNE0ucQQwyZ7uIS5bD6EPItwrrnsVatZEX ZVQcko2UvfHEq4LudlcDPZlEfe8JHF1hfA1d/y44ef4sFkAW5xPbGJO0z/JqfeZ8Bu2U XDDgJm2H1yPz+I0ZCSGLuqasRvncbXKT1/1+06KX3pP7Z6bYLWHwPx3SrnZZ0Aj4igLi UAaVQWllov6kEHTMh2RMRGeRNzwHzALK2zvM1EQFBNbw8NKiH1j8iubCfqvP86Qf+mcy Q+QD1kT4I2j0XB58RL2TbEK6xJL4ZtsrSopsh9SlgbQAMk/DHnUR1kLxxwyC0pj8thrc 5btw== X-Gm-Message-State: ANoB5pnCD47ABqq8oL52SBBoi2Htg8hgS/WN3+jDJKvQ+zDZgFnZWbji hPm4WbPZPQvdJnNqix2zjsYhvQHLiH4= X-Google-Smtp-Source: AA0mqf6lq6bevzMEdaG7j/wj1ThcnHfWPfi7pR6ccelcj/em9ndX0hDHklRXGENSFvMgDBFtK4SC4g== X-Received: by 2002:adf:d082:0:b0:236:4c79:7937 with SMTP id y2-20020adfd082000000b002364c797937mr63419wrh.641.1669045721673; Mon, 21 Nov 2022 07:48:41 -0800 (PST) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id fc18-20020a05600c525200b003c71358a42dsm24396234wmb.18.2022.11.21.07.48.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Nov 2022 07:48:40 -0800 (PST) Message-ID: <65a9ba28-182c-29a3-c8a9-93ed148b301d@gmail.com> Date: Mon, 21 Nov 2022 15:48:38 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 To: internals@lists.php.net References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com> Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly From: rowan.collins@gmail.com (Rowan Tommins) On 20/11/2022 13:20, Dan Ackroyd wrote: > This is getting quite complicated. > > I think unless someone makes a strong case for allowing the > combination of the two, disallowing them being combined is probably > the best choice. I'm inclined to agree. There's going to be a lot to understand and agree on this RFC as it is, so if some edge cases can reasonably be defined as forbidden, we're less likely to end up regretting some detail. Then if a good use case is identified, there can be a follow-up RFC, either within this release cycle, or in a future release. Regards, -- Rowan Tommins [IMSoP]