Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116787
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
In-Reply-To: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
Date: Mon, 3 Jan 2022 18:35:33 +0100
Message-ID: <CAB-BujakjsD5RD=_AoiK8q71sP1fxecAgfkpnqpe+UcC2WZLvg@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: andreas@dqxtech.net (Andreas Hennings)

One question that just occured to me:
Why allow the "public" keyword for visibility, if operators are public
automatically, and "private" and "protected" are not allowed?
Do we plan for private/protected operators in the future?
Shouldn't we eliminate meaningless choice?

On Mon, 3 Jan 2022 at 01:14, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
>
> Hello internals,
>
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
>
> To review past discussions on this RFC and the feature in general, please
> refer to:
>
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding
>
> Jordan