Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120230
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <eaaa805e-86b2-ce8c-5a24-c301260d16ac@php.net>
In-Reply-To: <eaaa805e-86b2-ce8c-5a24-c301260d16ac@php.net>
Date: Thu, 11 May 2023 00:28:33 +0200
Message-ID: <CAH5C8xUrNktmO=t1-357uE0UAZHe0O2zYdAxwE3a0Oo-MK7R=Q@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000e43d205fb5e65fd"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000000e43d205fb5e65fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Derick and Tim,

Derick, I incorporated most of your suggestions into the RFC with the sole
exception of the argument
names ($start/$finish,$begi/$end): it would feel odd if these parameters
and their related properties
were called differently:
https://www.php.net/manual/en/class.dateperiod.php#dateperiod.props.start

Actually, when we renamed the majority of parameters together with Nikita,
this was one of few rules that we had:
parameters should be called the same way as the property they initialize.


> Please no consecutive uppercase letters in the function name. I find
> createFromIso8601 (or createFromIso8601String if find the 'String'
> suffix useful) much more readable than createFromISO8601String.
> Uppercase acronyms are especially bad if followed by another ucfirst
> word, because the word boundary is not immediately visible there. Not
> the case here (it's digits), but still bad.


Yes, generally, I wholeheartedly agree, but unfortunately I still "had to"
go
with Derick's suggestion of using consecutive uppercase letters because
there
is already a DateTime::setISODate() method with the same casing and I want
to
follow the established naming convention of ext/date. Personally, I like
the "String"
suffix, probably it makes the name better, but since I don't really care
about this
problem too much, I'd leave it for Derick to decide about it.

M=C3=A1t=C3=A9

--0000000000000e43d205fb5e65fd--