Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109960
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>
 <CAPKYkKzkUt=TerFmn+ZBoPG0hMOWqQ6x924kRMEj4bVVm8B_Hw@mail.gmail.com> <CANeKSiS_b+cUmJFurFu0s=t+7M5Uh2aL69QZOfViOsKfpN_kag@mail.gmail.com>
In-Reply-To: <CANeKSiS_b+cUmJFurFu0s=t+7M5Uh2aL69QZOfViOsKfpN_kag@mail.gmail.com>
Date: Sat, 2 May 2020 00:23:14 -0700
Message-ID: <CANaX5nfM8AZmCsvFB7C_Bbx_jQdtgTLaKYi+_JrdFv7ki=_53Q@mail.gmail.com>
To: Benas IML <benas.molis.iml@gmail.com>
Cc: Chase Peeler <chasepeeler@gmail.com>, 
	=?UTF-8?Q?C=C3=B4me_Chilliet?= <come.chilliet@fusiondirectory.org>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000066cc8505a4a52c7b"
Subject: Re: [PHP-DEV] Renaming PhpAttribute to Attribute
From: davey@php.net (Davey Shafik)

--00000000000066cc8505a4a52c7b
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 29, 2020 at 08:24 Benas IML <benas.molis.iml@gmail.com> wrote:

> Hello,
>
> > 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
>
> With an introduction of any new language construct, function, class or
> constant, we don't know whether it affects closed source projects and we
> can't.
> So using your own logic, you can't assume that closed source projects use
> `Attribute` either.
>
> Another key term to take into consideration from my email is "in such cases
> isn't the first priority". That doesn't mean it doesn't matter, so please
> don't
> change my words as you please. Since PHP has global namespace reserved,
> things
> like implementation details matter much more **in such cases**.
>
> > 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.
>
> What I meant by `str_contains()` was its name. There were multiple PHP
> projects
> that offered a global helper function called `str_contains()`. As such,
> introduction of this function was also a name clash for them.
>
> > 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.
>
> Well then you shouldn't take everything so "harshly" and as a debate. There
> are
> no "arguments" here, I am simply expressing my own opinion.
>
> As for naming inconsistencies, Rowan addressed that already.
>
> Best regards,
> Benas Seliuginas.


Hi all,

IMO, the onus of proof should be on those wishing to introduce a change
that has a potential conflict, not those trying to prevent one.

I believe that using the PHP namespace is the right way to go, and look
forward to seeing code like this in the future:

<?php
namespace Dshafik;

use PHP\Attribute;

<<Attribute>>
class Foo { }

- Davey

--00000000000066cc8505a4a52c7b--