Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101334 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21229 invoked from network); 12 Dec 2017 13:43:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Dec 2017 13:43:45 -0000 Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.53 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.214.53 mail-it0-f53.google.com Received: from [209.85.214.53] ([209.85.214.53:40265] helo=mail-it0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 05/53-53433-E0DDF2A5 for ; Tue, 12 Dec 2017 08:43:44 -0500 Received: by mail-it0-f53.google.com with SMTP id f190so24298613ita.5 for ; Tue, 12 Dec 2017 05:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+AHTj8kaBr/IXFAuPyoZYsMtJ/MHXG2XrnXh/CpsJpc=; b=DDsvnNumrzrpzt7612WGwSTOoM2qM9CL8Y/x7umjzmRct/mndoD8keJ+S00Rc/K5Cg V26WrDNKlo1M1NHMbxTMcEEwy57YMNJd4iOvHc0lDElQnzNgyPuw+QXuoi+GDCy2l/YY x1joNyW7R6wCa1Il/+UNtbSCpQpudKOKD9Td5hbqiUhKr94G0rxuuT8n4DTkrShAh/6g jQJyxB8otlNzuRji+YQcTCBfCLEM6Xba8A6bFICaoYiDQhP0vUWOuuKspmbE6pISR0Dr A5TlD7D9yJOF39V5+pzeHOv6IKsw/zm//M9WakXsXGRMPoKZIwPWmKPtUvd1lrN7w0bY 8Geg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+AHTj8kaBr/IXFAuPyoZYsMtJ/MHXG2XrnXh/CpsJpc=; b=M0Qj+pQPc77pkovQlgohOynCv+RA3VdmfdiLBbhAmTagY9S/Ji4UNEC9M0O0L/IRuz x6wPyIs8U1fWcPURAquPpL/2a0h06k6+rg3Wc/LZpM78mWEYil6ogM+qxeL1OPJmC3FN /tytHmQHniCPrSAjYPCTp+ZfkxC2e57axIdtJ/+fxn44Ht+aL0Jed+jzJ1K4mvC+i97i Z9D7yq19S/9QT8qpKSFtjzLkJhgzSa7ImTQ5nzrz/LL7VsgvXFCkLS9su4CsHYzjq+OV Z/9cw31lvjXKVzD+0Q1Lm0EmDexFYwzybUDarsLDYKXdmEMc47Frrr8i9Sq8C+xOq4b3 iTyg== X-Gm-Message-State: AKGB3mL4sRJXQfY90cmfqN63CiHIv07xTBEE66KJ0TLwOLCv+p9GGA/q Ej4+DSc+26QUbg6XSolb2JfK3ejmiZKSovDPdFo= X-Google-Smtp-Source: ACJfBotrbN84FcCALFShln2wgkIvxi0piTbX1k2tVRes1Ev4/QK4q9q80/2biDxoqg1d/QM6Lq3HbLr20S2+yumaYKU= X-Received: by 10.36.44.197 with SMTP id i188mr2706750iti.40.1513086219849; Tue, 12 Dec 2017 05:43:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.93 with HTTP; Tue, 12 Dec 2017 05:43:39 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Dec 2017 14:43:39 +0100 Message-ID: To: Stanislav Malyshev Cc: PHP internals Content-Type: multipart/alternative; boundary="001a1143d330a6174e056024d6ef" Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares, again From: nikita.ppv@gmail.com (Nikita Popov) --001a1143d330a6174e056024d6ef Content-Type: text/plain; charset="UTF-8" On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev wrote: > Hi! > > > The idea is to allow specifying declare directives for a whole library or > > project using: > > > > namespace_declare('Vendor\Lib', ['strict_types' => 1]); > > I am not sure I like this. Namespace is a prefix to a class name. > Anybody can declare a class with any name, and the side-effect that they > would inherit some context, which is completely invisible and would > magically exist somewhere globally, does not seem like a good idea to > me. Moreover, what if something - like older version of the same library > or test or something like that - would have different idea about what > that global state should be? How nice would it be if a piece of > unrelated code could completely change how my code is interpreted? How > nice would it be if whether it works or not would depend on in which > order classes were loaded in this particular request? > The way PHP works, it's not possible to have two versions of a library loaded at the same time. There are projects like https://github.com/humbug/php-scoper to allow loading a library multiple times, which work by prefixing all namespaces. Of course, in this case namespace_declares() would also be applied to different namespaces and there will be no interference. There is no dependence on loading order. The implementation is careful to ensure that the used declare state is consistent. It's not possible to call namespace_declare() twice on the same namespace. It's not possible to first load some files from a namespace, do the namespace_declare() call and then load some more files. If a namespace_declare() call succeeds without throwing an error, then that is the ground truth, without any dependence on order or other calls. > Hidden global context has the same smell as php.ini settings, and for > the same reason - but this, as far as I can see, will also be hidden and > depending on file loading order, class loading order, etc. which in big > applications can lead to a lot of fun debugging why some code randomly > produces fatal errors... Debugging PHP is fun enough without quantum > entanglement-like effects :) > As said above, the implementation makes sure that all quantum state is collapsed ;) The only possible mistake that can occur is that the namespace_declare() call doesn't happen at all, but anything depending on loading order or conflicting calls is not possible. The big issue with ini settings is (mostly) not the "hidden" part, it's the "global" part. Ini settings that change language behavior are tabu because they apply to everything, so no library can assume any particular ini configuration. Namespace-scoped declares explicitly avoid this. A library can namespace_declare() it's configuration and be sure that this is the configuration it's going to get, at the same time not interfering with any other library or code that uses a different configuration. > The reason why I'm picking it up again is some feedback I received for the > > explicit call-time send-by-ref proposal. The main objection seems to be > > that the feature has limited usefulness if it's optional rather than > > required, because you still can't be sure that something is a by-value > > pass, just because no & is present. At the same time, we can't make this > > required anytime soon due to the large BC impact. > > Where "soon" means "for all practical purposes, forever, unless we stop > calling that new thing PHP", IMO. > > > Namespace-scoped declares are perfectly suited to resolve this problem. > We > > I don't think so. First of all, I don't think, of course, that this > problem needs to be solved by adding more complexity to save a purely > cosmetic feature. But second of all, I don't think global hidden context > that could change at a distance how the code is interpreted is a good > idea regardless of whether it solves the issues with send-by-ref. > I haven't thought too carefully about whether having an option for the explicit-send-by-ref feature *specifically* would be beneficial, but I think it's very important to at least have the option on the table. Too many issues in PHP cannot be solved for reasons of backwards-compatibility. We need to have *some* way to evolve the language without BC breaks, and I think namespace-declares are an elegant way to do this. Regards, Nikita --001a1143d330a6174e056024d6ef--