Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116657
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com> <CAMrTa2E9STK3G52mnQ9UsrUqi_bH4SMUzcE76PEGcxcLzGPVZA@mail.gmail.com>
 <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org>
In-Reply-To: <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org>
Date: Thu, 16 Dec 2021 18:30:43 +0000
Message-ID: <CA+kxMuQm28GcVz3G1txzWpGMjgXZa87Ybf7L9p_jKx99Ob7=BA@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: Danack@basereality.com (Dan Ackroyd)

On Thu, 16 Dec 2021 at 08:24, Pierre <pierre-php@processus.org> wrote:
>
>
> If the names are a problem, why not registering those using an attribute
> ?

If there is a strong reason to use attributes, then the argument
should start from there.

Starting from "well we could just use an attribute" and then putting
the pressure on other people to find a reason to _not_ use an
attribute, is a terrible design process.

Every language that has annotations ends up with far too many of them;
PHP is likely to end up with too many of them also. The time to push
back against using them is now, not when the damage has been done.

But to repeat, I don't think the names of magic methods are a problem.
Documenting that 'the name refers to the operator sigil, not to what
the function does', avoids it being a problem to be solved.

cheers
Dan
Ack