Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121225 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10452 invoked from network); 4 Oct 2023 23:42:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Oct 2023 23:42:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2F81218004A for ; Wed, 4 Oct 2023 16:42:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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-oo1-f44.google.com (mail-oo1-f44.google.com [209.85.161.44]) (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 ; Wed, 4 Oct 2023 16:42:47 -0700 (PDT) Received: by mail-oo1-f44.google.com with SMTP id 006d021491bc7-57babef76deso222144eaf.0 for ; Wed, 04 Oct 2023 16:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696462967; x=1697067767; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SwiZotfodOErBP+vzNKar5Vtwe5szuTAZtiWtLowuAU=; b=JNt4WLOufL9Ki+YxiXV/0yv7sIld/ucvNmKtPmcF3helz7uCeDAF7gACf4SiPIGBM8 heZUhi+etRxKS+658HEcD3x0FeEQK1qygSI8ArOumT5FvC55qqe2vNhAi+HVjIpDypV6 cjir6eO1WS+7PIEaXP9Ub2QRvDYUoyWw02sFkiW91pWiqxg34Wy7MdluY9E/WajMdkCo 6sOMo+RPMSr4uOSDvNvXdyXEK/tPeZaa9fLhX813u2atCXN1ldODqhHbe0L6EX2HuqGj YoztsmGVaN1Jb8LyKNfaMdwlnmmD/EJ86NII425/ZtqNMZARoBFRWsOLYEYSx0itlOOl jbmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696462967; x=1697067767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SwiZotfodOErBP+vzNKar5Vtwe5szuTAZtiWtLowuAU=; b=H28F8t4kjeFntiHdEWpcgUdeIAtSTJNq80rdLy68qAqGlahO3FaHR0DMD8I1/6Do0k /z5RLx8wNL4Vq0e7OjD6Nc7ioAC/Efgi0m4LjJ8EusmhIjiA/DwoVbI4TyICVbS1hE2K ydsZ25Nwer0D9YrweUyh1n87/nlPvMlpuyVG7oJYpJNpzmebttYy5fxVZ6rSm52CNdiH /mqT9+tK9o1/TksiF0gtpK4GIn2SuvJmfGPme08cxTpVvwXxrpJfxZOULUImRtzZpAlb 7GkZQBs4UUvHbkLEJtBUd7xO0sjWQ3KQmzmmNethZOLKIvsCOacJeqJrDN2FlM13uaQy NIxQ== X-Gm-Message-State: AOJu0YxS2bby7KvS6oyyRWciZAVutqsMfzEtgRywdNJLYXyMOmMuTcaj G2xClGDUdVW6y+zibmYw7Sqe4QNC5x8IJIapQ3o= X-Google-Smtp-Source: AGHT+IEktIrB4yGu77W4MWSCTvuxgdJRrCaD84tsWBASpiL71TypCSvYnJSe6n1YjzPh3dqhRJO50UFBzkSafc9h5+Y= X-Received: by 2002:a05:6358:591c:b0:143:7d73:6e66 with SMTP id g28-20020a056358591c00b001437d736e66mr4393143rwf.1.1696462966802; Wed, 04 Oct 2023 16:42:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 5 Oct 2023 00:42:35 +0100 Message-ID: To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Cc: PHP Internals List Content-Type: multipart/alternative; boundary="00000000000082cdc90606ec90c3" Subject: Re: [PHP-DEV] proc_open() resource to opaque object migration From: george.banyard@gmail.com ("G. P. B.") --00000000000082cdc90606ec90c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 28 Sept 2023 at 21:20, M=C3=A1t=C3=A9 Kocsis wrote: > Hi Everyone, > > I'm writing in connection with a question coming up lately during the > "resource to opaque object migration" project ( > https://github.com/php/php-tasks/issues/6) which we have been working on > for quite a long while. > > During the review of my PR migrating the resource returned by proc_open() > to an object (https://github.com/php/php-src/pull/12098), it quickly > became > evident that there was no consensus about the new class name, since the > originally proposed "Process" name has a non-negligible BC break > likelihood. > > That's why we should find the best class name in accordance with Nikita's > namespace naming convention RFC ( > https://wiki.php.net/rfc/namespaces_in_bundled_extensions). Even though m= y > PR currently implements "Standard\Process", this name is not a good > candidate according to the policy: > > Because these extensions combine a lot of unrelated or only tangentially > > related functionality, symbols should not be namespaced under the Core, > > Standard or Spl namespaces. Instead, these extensions should be > considered > > as a collection of different components, and should be namespaced > according > > to these. > > > Does anyone have a good suggestion? > If there needs to be a namespace, we could take inspiration from Python and use OS\Process, as everything relating to processes seem to reside in the os module. Best regards, George P. Banyard --00000000000082cdc90606ec90c3--