Re: (Planned) Straw poll: Naming pattern for `*Deque`
| From: | Pierre Joye | Date: | Tue, 11 Jan 2022 03:35:14 +0000 |
| Subject: | Re: (Planned) Straw poll: Naming pattern for `*Deque` | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116861@lists.php.net to get a copy of this message | ||
Hi Tyson,
On Tue, Sep 21, 2021 at 9:19 AM tyson andre <tysonandre775@hotmail.com> 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