Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116861 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23475 invoked from network); 11 Jan 2022 02:26:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Jan 2022 02:26:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 509941804C3 for ; Mon, 10 Jan 2022 19:35:27 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS 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-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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, 10 Jan 2022 19:35:26 -0800 (PST) Received: by mail-ot1-f41.google.com with SMTP id h20-20020a9d6f94000000b0059100e01744so355774otq.4 for ; Mon, 10 Jan 2022 19:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sy8aVqm4FBIw6USdeO1Wsnh1Gu6ABxTbJGvJ9RLxvMU=; b=FexZgG3OpiRXdGncmsfz8P2meapJIiJpGUMVSPgwEy59srEUps3d8/2kKiZhiBIS0V 9SkrRUiaE0ZIwiK7eg7+PQs2hsyaTgik8UqCI4nVUFYes08RNigWgTzDquS7pgrOsr7I v0UUKvH4Um4AQP1yZSFfxGCJEk+ZgXeJPH5asRmBc75qzmzwRqD0+OW2HQbJUOyDo0T5 14Dupe2BLDlPc9ejix/cRqt/m6Ezv79ZiscO1llmEJlBSbVfZZYafcuO1UF4381RwI9q m/sztb0DKntw94Hrx2vbU+KK+BIGq2xVUIcyFFT+EFpPS5o5dAmLb7m5LKaGpu3lGTSB S9mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sy8aVqm4FBIw6USdeO1Wsnh1Gu6ABxTbJGvJ9RLxvMU=; b=buGkR/XSNwiRL2huHxHTiQ2ViBmhXd0jPuAgyrrziaJEybQchw60Vu9QSU9ShohCLz diHvBrn8g+0DHrorSZT25oJvd+9G+z7K6eqDC9z8WDbei4MZKvF0aih2gLX0L16j/Fu9 +pOqEbI8Qtbcp8LMElzPZyk3OVzCKxdD3GTodpzOW8KgwEf0CqIBSbs8/tECbPqwhzdL nvZTSf5uoX3hqWmaYDGFRiVHeXq2Tp7cXXPPvMJwJuJHYR3mnCPnKDquMexzr/xE309x Di1GBAloFocZn7ytxAHgHDgbX0yzVdrplJ3AEDDWHa6PX6FuUIkzYJCmH/pRxMlFO9x9 IWow== X-Gm-Message-State: AOAM530YAGpy1Jg2Eb/cpl2qfsG29iKvd+Wy0YFyANmelR06WpO7NBKM 7ZpEtCfdAqpDEDhQh+DE+sBW9hOj+Ev7CYeeGII= X-Google-Smtp-Source: ABdhPJyGeKaw7Kz9h3cOUxYUQMx4CXbueEYAMhx3vIpsxWAT8PN1qxC43U6nu99GisBImxLBHq/rPIrZPJ4UvuMPgm4= X-Received: by 2002:a05:6830:22ef:: with SMTP id t15mr2114140otc.69.1641872125987; Mon, 10 Jan 2022 19:35:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 11 Jan 2022 10:35:14 +0700 Message-ID: To: tyson andre Cc: "internals@lists.php.net" Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] (Planned) Straw poll: Naming pattern for `*Deque` From: pierre.php@gmail.com (Pierre Joye) Hi Tyson, On Tue, Sep 21, 2021 at 9:19 AM tyson andre wrote: > > While there is considerable division in whether or not members of internals want to adopt namespaces, > I hope that the final outcome of the poll will be accepted by members of internals > as what the representative of the majority of the members of internals > (from diverse backgrounds such as contributors/leaders of userland applications/frameworks/composer libraries written in PHP, > documentation contributors, PECL authors, php-src maintainers, etc. (all of which I expect are also end users of php)) > want to use as a naming choice in future datastructure additions to PHP. > (and I hope there is a clear majority) > > ----- > > Are there any other suggestions to consider for namespaces to add to the straw poll? > > Several suggestions that have been brought up in the past are forbidden by the accepted policy RFC (https://wiki.php.net/rfc/namespaces_in_bundled_extensions) > and can't be used in an RFC. > > - `Spl\`, `Core\`, and `Standard\` are forbidden: "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." > - More than one namespace component (`A\B\`) is forbidden > - Namespace names should follow CamelCase. Besides the namespace thing (collection is fine imho). What is the reason to have it final? For collection in general, would it make sense to have a common interface representing the minimum expected API? If possible, then algorithm specific on top? a bit like we have with the traversable interface and related. best, -- Pierre @pierrejoye | http://www.libgd.org