Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109928
MIME-Version: 1.0
References: <CANeKSiRbPFbP9GjWdwbQ3J4oLP2wjKGoxnz1EbVb9K0aejg4EQ@mail.gmail.com>
 <CADyq6sLw8tKcqV0ukjbkey5tXEraTk6zzbbTXB8_0_wO0xO6jQ@mail.gmail.com>
 <CANeKSiQJuMkF0Hyc+8GDoUVc_MNs_xtt+y97qv+LMuOCAtotEQ@mail.gmail.com>
 <4063585.LhOdPkFbeG@mcmic-probook> <CANeKSiRq4GDwHEk8Jyxf8LmC2V0Aqdeouki+BytxwShzJ1KaFQ@mail.gmail.com>
In-Reply-To: <CANeKSiRq4GDwHEk8Jyxf8LmC2V0Aqdeouki+BytxwShzJ1KaFQ@mail.gmail.com>
Date: Wed, 29 Apr 2020 10:41:29 -0400
Message-ID: <CAPKYkKzkUt=TerFmn+ZBoPG0hMOWqQ6x924kRMEj4bVVm8B_Hw@mail.gmail.com>
To: Benas IML <benas.molis.iml@gmail.com>
Cc: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come.chilliet@fusiondirectory.org>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000362edf05a46ef2ef"
Subject: Re: [PHP-DEV] Renaming PhpAttribute to Attribute
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000362edf05a46ef2ef
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 29, 2020 at 9:35 AM Benas IML <benas.molis.iml@gmail.com> wrote:

> Hello,
>
>
I honestly don't care what it's called, but I am seeing some arguments
being used in favor of changing it that I think are invalid.


> Since your project is just a single example, we still can't make such a
> bold
> claim that `\Attribute` is used a lot.
>
>
As with any possible BC break, the issue isn't what we know, but what we
don't know. It's the potential impact to closed source or other proprietary
projects out there, weighed against the benefit. Since "Attribute" is a
pretty common term in programming, the odds of some of those projects
having an Attribute class in the global namespace is higher than some
esoteric term rarely used in a programming context.


> While "attribute" is a fairly generic word, just about everyone uses
> namespaced
> classes and therefore it's not a huge problem. Moreover, PHP 8 is a major
> release so BC in such cases isn't the first priority.
>
>
Again, your assumption that just about everyone uses namespaced classes
doesn't take into account closed source projects.  I don't care if it's a
major release or not - BC breaks should always be avoided without a major
benefit


> Also, it's important to mention that the introduction of functions such as
> `str_contains()` is also a breaking change for some. But the benefits it
> provides outweigh the 0.1% who may get BC issues.
>
>
str_contains adds functionality to PHP. We aren't debating whether to add
attribute functionality to PHP, but what to call it. As such, this argument
is an invalid comparison.


> Best regards,
> Benas Seliuginas
>

I don't think PhpAttribute is a bad name. Per the RFC: "Attributes as a
form of structured, syntactic metadata to declarations of classes,
properties, functions, methods, parameters and constants. Attributes allow
to define configuration directives directly embedded with the declaration
of that code." - In other words, they are Attributes of PHP constructs.
While that additional Php might not be necessary to avoid ambiguation in
the same way it was for Token, I don't think it's an improper
disambiguation either.

As Derick said below "PHP owns the top-level namespace but tries to find
decent descriptive names and avoid any obvious clashes." - These seems like
a prime example of using "descriptive names" to "avoid any obvious clashes"

As I said above, I'm ambivalent about this particular issue. However, I get
nervous when I start to see the "Who cares if it breaks stuff" or "Well,
they shouldn't be doing it that way, so screw them" arguments pop up. While
the chances of a BC break might be minimal using "Attribute" - I don't
think that PhpAttribute is an undue burden in an attempt to avoid such
instances, nor is it logically inconsistent with other Php* named classes.

-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000362edf05a46ef2ef--