Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109931 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28287 invoked from network); 29 Apr 2020 16:50:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Apr 2020 16:50:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BAC09180531 for ; Wed, 29 Apr 2020 08:24:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 29 Apr 2020 08:24:22 -0700 (PDT) Received: by mail-lj1-f171.google.com with SMTP id e25so3057249ljg.5 for ; Wed, 29 Apr 2020 08:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N16s+um95qKdgPGn9NESduNPQhXRMeIIX7tnhPxNdVw=; b=eSqwFRtNJVsKOWVokFZqeeWIYoZKIaT2tBPRYn+WaWbe13DIzeUvdi0kCyB/q3chzH xx+UwmaU9Y/SAn6OCjtCMh6jMIMOJY36rwuT98SlN6v5HHg7zh0AUIGVgvAPVymLFMQV CasvTMPJGSx1SPT1daXN3UlPCgcmnfshZCIutaVBXwdcjdwzc0GwbLjJn3LOfUDQsyN2 S02mDgiNnVO7/oIeVydlQK3AHYEPRgS1/M8ANFbPkFMRZ04j6L8SaKYXg3vVyQMT2LiK HTw+kJmGobkAPzfUX/4rqYUsfYW6oqoLsFvZ206NEeNouK8y1/2N1J9gLe9O5K97+NxM 1wLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N16s+um95qKdgPGn9NESduNPQhXRMeIIX7tnhPxNdVw=; b=J5JYEPqPZj5clgxkkS2MLCQplQyIkVyqf2GSpTtLTcBMEvmC4eK5DCaHst85HEDsyl CzbhcyWzsbpQoOs5CSAfp7CD5MGkfJEzWdn4kTocJIrDbtJlFHjCfK3FTeRq53IkOUE+ A5pIYTwWyk6oj/OwRt7pVfVlfX7d/LpQKCvdTATUPeBLebgpEsP5OdIeV330Fy00WKst 9/YRpvEUCAwboQTwJWpvLziWIUBOKW5hIuXCPmCe3pOPKL+ni8XahD1KEml6WAKLgr8p Q36whV+jEyaC2+X6vRTcpOMm9p9WXaURBZkl6LemWgMjT8JvqLoV5+8+oU1XUEzb9Ipu 6a7Q== X-Gm-Message-State: AGi0PuY8KPaxvcPcP3MJYqTFhMKb9Kvc46ANXBJWkxTBpFngu60rFbFY VWCZWk2DdWeTzkHgzgoxUh31wlPGzMZpdws8Rn8= X-Google-Smtp-Source: APiQypJNd7mVCkbZSJkIsZK334U9uSpXEuX6mAfZbV4P/AEOIs4ljRoGTiyNQlIailChpibNi/boJN5P8fjkm/UX3s8= X-Received: by 2002:a2e:920e:: with SMTP id k14mr22284140ljg.288.1588173858953; Wed, 29 Apr 2020 08:24:18 -0700 (PDT) MIME-Version: 1.0 References: <4063585.LhOdPkFbeG@mcmic-probook> In-Reply-To: Date: Wed, 29 Apr 2020 18:24:05 +0300 Message-ID: To: Chase Peeler Cc: =?UTF-8?Q?C=C3=B4me_Chilliet?= , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000b45d7305a46f8a9e" Subject: Re: [PHP-DEV] Renaming PhpAttribute to Attribute From: benas.molis.iml@gmail.com (Benas IML) --000000000000b45d7305a46f8a9e Content-Type: text/plain; charset="UTF-8" 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. --000000000000b45d7305a46f8a9e--