Hi Derick,
In any case, I don't mind this — I'm actually going to suggest to change
> the constructor to:
>
> public function __construct(DateTimeInterface $start, DateInterval
> $interval, DateTimeInterface|int $end, int $options = 0) {}
>
> And then *only* add:
>
> public static function createF
On Mon, 19 Jun 2023, Nicolas Grekas wrote:
> > > On my side, I'd very much prefer keeping the constructor of
> > > DatePeriod and thus making it non-overloaded with this signature:
> > >
> > > public function __construct(DateTimeInterface $start, DateInterval
> > > $interval, DateTimeInterface|i
Hi Rowan and Larry,
> Isn't that exactly what a deprecation period is for?
>
Yes, sure, but I wrote my arguments with the "Short deprecation period" in
mind so that the removal of
these functions causes the least pain.
> If we want to give people longer, just leave the functionality deprecated
On Wed, Jun 21, 2023, at 11:57 AM, Rowan Tommins wrote:
> On Wed, 21 Jun 2023 at 09:43, Máté Kocsis wrote:
>
>> The reason why I think it's a good approach to have an intermediate state
>> is to give
>> these people the possibility to defer the actual migration until the
>> very end.
>>
>
>
> Isn'
On Wed, 21 Jun 2023 at 09:43, Máté Kocsis wrote:
> The reason why I think it's a good approach to have an intermediate state
> is to give
> these people the possibility to defer the actual migration until the
> very end.
>
Isn't that exactly what a deprecation period is for?
If we want to give
Hi Bruce,
For those who use callbacks now, how is this in any way better? They will
> eventually end up using an OOP approach anyway (as that's the strategic
> goal).
> Migrating from `session_set_handler_callbacks()` would still be
> (potentially)
> non-trivial. And what's the point migrating *to
On Wed, Jun 21, 2023 at 12:54 AM Máté Kocsis wrote:
> * In order to finally achieve the strategic goal, we deprecate the old
> function along with session_set_handler_callbacks()
> as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z,
> whatever.
For those who use callbacks now,
HI Nicolas and Rowan,
Mate, WDYT of 2)?
Your sentence about better typing rang a bell with me: I think that's the
best argument
for removing the signature accepting callables. But before coming to a
conclusion,
let me answer Rowan's question first:
This is where I don't understand what you or M
On Tue, 20 Jun 2023 at 09:22, Nicolas Grekas
wrote:
> > So are you saying we should deprecate the function-based version
> > completely, and not provide any new names at all? I think I would prefer
> > that to the confusing set of aliases the current RFC text proposes.
> >
>
> I was not but I wou
> Then, among both options, we need to select the one with the best future
> > proofness, and that's definitely the OOP one to me, because it comes with
> > more guarantees (type checks).
>
>
> So are you saying we should deprecate the function-based version
> completely, and not provide any new na
On 20/06/2023 07:26, Nicolas Grekas wrote:
Then, among both options, we need to select the one with the best future
proofness, and that's definitely the OOP one to me, because it comes with
more guarantees (type checks).
So are you saying we should deprecate the function-based version
complet
Hi Juliette,
Respectfully though, in my opinion selectively leaving out impact analysis
> without mentioning why they are missing in the RFC, reeks of trying to hide
> information which could influence the vote.
> Maybe just mentioning why the impact analysis is missing in these cases in
> the RFC
Le lun. 19 juin 2023 à 22:33, Rowan Tommins a
écrit :
> On 19/06/2023 21:17, Nicolas Grekas wrote:
> > I think we must account for a bit of history/legacy on the topic.
> > I think session_set_save_handler(SessionHandlerInterface) is the best
> BC/FC
> > path we can provide.
>
>
> Can you elabora
On 19-6-2023 23:16, Máté Kocsis wrote:
Hi,
The impact analysis on userland code seems to be missing for some of the
proposals, most notably for the proposals which I expect will have the
highest impact. I'd like to ask for an impact analysis to be added to
each of these:
* array_keys()
* Refl
Hi,
The impact analysis on userland code seems to be missing for some of the
> proposals, most notably for the proposals which I expect will have the
> highest impact. I'd like to ask for an impact analysis to be added to
> each of these:
> * array_keys()
> * ReflectionProperty::setValue()
>
Thes
On 19/06/2023 21:17, Nicolas Grekas wrote:
I think we must account for a bit of history/legacy on the topic.
I think session_set_save_handler(SessionHandlerInterface) is the best BC/FC
path we can provide.
Can you elaborate? The SessionHandlerInterface is the *newer* of the two
current signat
Le mer. 14 juin 2023 à 23:51, Máté Kocsis a écrit :
> >
> > Given that you've agreed that neither signature is "primary" or "better",
> > doesn't that argument apply equally to both signatures? If it's OK to
> force
> > anyone using individual callbacks to change their code, why is it not
> > equ
> > > I'm going to nitpick on the newly suggested names and argument order
> for
> > > the
> > > DatePeriod factory methods — althoughI do agree that they need to get
> > > created:
> > >
> > > createFromInterval(DateTimeInterface $start, DateInterval $interval,
> > > DateTimeInterface $end, int $o
On 27-4-2023 23:28, Máté Kocsis wrote:
Hi Internals,
As you have possibly already experienced, overloaded signatures cause
various smaller and bigger issues, while the concept is not natively
supported by PHP. That's why I drafted an RFC which intends to phase out
the majority of overloaded func
On Wed, Jun 14, 2023 at 4:06 AM Derick Rethans wrote:
>
> On Tue, 13 Jun 2023, Nicolas Grekas wrote:
>
> > > I'm going to nitpick on the newly suggested names and argument order for
> > > the
> > > DatePeriod factory methods — althoughI do agree that they need to get
> > > created:
> > >
> > > cre
On 14/06/2023 22:51, Máté Kocsis wrote:
The whole discussion about also deprecating the other one started only
because of improving naming:
it is also a nice thing to pursue but fails the cost-benefit analysis.
In my mind, making two new names, both unambiguous, gives a greater
benefit (a cle
>
> Given that you've agreed that neither signature is "primary" or "better",
> doesn't that argument apply equally to both signatures? If it's OK to force
> anyone using individual callbacks to change their code, why is it not
> equally OK to force anyone using an object to change their code?
>
A
On Tue, 13 Jun 2023 at 15:49, Máté Kocsis wrote:
> I understand that communication is much simpler with your suggested
> approach, however, deprecating something which everyone surely uses partly
> undermines the efforts we have made for ensuring as much backward
> compatibility as reasonably pos
On Tue, 13 Jun 2023, Nicolas Grekas wrote:
> > I'm going to nitpick on the newly suggested names and argument order for
> > the
> > DatePeriod factory methods — althoughI do agree that they need to get
> > created:
> >
> > createFromInterval(DateTimeInterface $start, DateInterval $interval,
> > Da
Hi Nicolas,
On my side, I'd very much prefer keeping the constructor of DatePeriod and
> thus making it non-overloaded with this signature:
>
> public function __construct(DateTimeInterface $start, DateInterval
> $interval, DateTimeInterface|int $end, int $options = 0) {}
>
> That'd help a lot wit
>
> > As you have possibly already experienced, overloaded signatures cause
> > various smaller and bigger issues, while the concept is not natively
> > supported by PHP. That's why I drafted an RFC which intends to phase
> > out the majority of overloaded function/method signatures and also
> > fo
>
> It looks like the current preferred signature was only introduced in PHP
> 8.2. Previously, the signatures were dba_fetch($key, $handle) and
> dba_fetch($key, $skip, $handle) - it effectively had a non-final optional
> parameter.
>
Yes, that's the case! Thanks for reminding me again, I clarifi
>
> In my mind, the only reason to change anything about this function is that
> we can't properly overload a function based on its argument types. There's
> nothing particularly "primary" or "better" about either of the two
> signatures, it's just hard to document and use named parameters while
>
On Sat, 10 Jun 2023 at 08:40, Máté Kocsis wrote:
> In the meanwhile, I noticed yet another overloaded function (dba_fetch())
> and I included it into the proposal. In my opinion, it's a no-brainer
> to deprecate due to its low adoption rate and very odd behavior - to say at
> least.
>
It looks
On 10 June 2023 08:31:24 BST, "Máté Kocsis" wrote:
>Hmm, that's also a very good idea, and I support this. However, I'm
>hesitant to deprecate the 2 parameter version of session_set_save_handler()
>just yet,
>since doing so would mean that everyone using sessions has to use a new
>function... Inst
Hey Everyone,
In the meanwhile, I noticed yet another overloaded function (dba_fetch())
and I included it into the proposal. In my opinion, it's a no-brainer
to deprecate due to its low adoption rate and very odd behavior - to say at
least.
The RFC evolved a lot during the discussion phase, thank
I'm forwarding my mails which I managed to only address for Rowan:
Hi Rowan,
> If we go down that route, perhaps we should come up with a corresponding
> name for the object based version - "session_set_handler_object" perhaps?
> That would also mean the deprecation messages can be much simpler:
On Tue, 30 May 2023 at 09:54, Claude Pache wrote:
> Any change that introduce a BC break or a migration burden must be
> justified. (There has been enough rant around justified BC breaks, so let’s
> not introduce unjustified ones.)
>
> What is the purpose of changing the return convention of Intl
On 2 June 2023 14:21:49 BST, "Máté Kocsis" wrote:
>I hope that I don't sound elitist, but codebases not using static
>analysis... are kind of hopeless...
Then I guess we should just pack up and go home, because right now PHP doesn't
even have an official static analyser, let alone a mandatory o
On 17 May 2023 08:35:18 BST, "Máté Kocsis" wrote:
>Particularly, I have been wondering for a long time, why the original
>function includes "save_handler" in its name?
>The passed in handlers are not just "save", but also other kinds of
>handlers (e.g. "read"). So I'm considering to use
>somethin
Hi Claude,
The very risk is that the programmer must be aware that the return
> convention has changed. Recall that not everyone run static analysers,
> especially for such a trivial migration, and that not every code is
> statically analysable (e.g.. `$foo->$bar()`).
>
I hope that I don't sound
Hi Máté,
> Le 30 mai 2023 à 01:41, Máté Kocsis a écrit :
>
> Hi Claude,
>
>> The replacement methods for IntlCalendar::set() (namely
>> IntlCalendar::setDate() and IntlCalendar::setDateTime()) must not have a
>> return type of `void`, but `true`, like the original method, for the two
>> foll
Hi Claude,
The replacement methods for IntlCalendar::set() (namely
> IntlCalendar::setDate() and IntlCalendar::setDateTime()) must not have a
> return type of `void`, but `true`, like the original method, for the two
> following reasons:
>
> 1. By changing the returned value, you are introducing a
> Le 27 avr. 2023 à 23:28, Máté Kocsis a écrit :
>
> Hi Internals,
>
> As you have possibly already experienced, overloaded signatures cause
> various smaller and bigger issues, while the concept is not natively
> supported by PHP. That's why I drafted an RFC which intends to phase out
> the m
Hi Everyone,
Yesterday, I updated the voting choices based on Rowan's suggestions. I
also picked a few signatures where
only one migration path is proposed (the short one).
Now, I'd be curious what to do with the FFI methods in question (
https://wiki.php.net/rfc/deprecate_functions_with_overload
On Tue, May 16, 2023, at 2:26 PM, Derick Rethans wrote:
> On 15 May 2023 13:38:56 GMT-05:00, Larry Garfield
> wrote:
>>On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
>>> On 15 May 2023 09:54:41 BST, "G. P. B." wrote:
>>>
Why are we assuming that PHP 9.0 is going to come after PHP 8.4
On 15 May 2023 13:38:56 GMT-05:00, Larry Garfield
wrote:
>On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
>> On 15 May 2023 09:54:41 BST, "G. P. B." wrote:
>>
>>>Why are we assuming that PHP 9.0 is going to come after PHP 8.4?
>>
>> Historically, PHP has had a major release roughly every
On Sat, 13 May 2023 at 00:08, Larry Garfield wrote:
>
> That means it's impossible to write code that works from 8.2 to 9.0 without
> version checks. The overlap period is only 2 releases (8.3 and 8.4). That's
> too short of a window.
That it is too short, is an opinion.
Having one version w
On Tue, 16 May 2023 at 12:03, G. P. B. wrote:
>
> Because this proposal of "let's do majors every 5 years" now reduces what
> we can do, as we cannot (or should not) deprecate stuff in X.0, as it makes
> it harder for people to upgrade to the new major (see how we postponed the
> 8.0 deprecation
On Mon, 15 May 2023 at 19:39, Larry Garfield wrote:
> Tangent: If I were to put together an RFC that set out such a 5 year cycle
> expectation with reasonable guidelines around when things could be
> deprecated, would anyone actually support it?
>
No, as this doesn't solve the problem.
Best reg
On Mon, 15 May 2023 at 19:36, Rowan Tommins wrote:
> On 15 May 2023 09:54:41 BST, "G. P. B." wrote:
>
> >Why are we assuming that PHP 9.0 is going to come after PHP 8.4?
>
> Historically, PHP has had a major release roughly every five years. The
> main exception is PHP 6, which was never release
> On 15 May 2023, at 19:51, Rowan Tommins wrote:
>
> On 15 May 2023 19:38:56 BST, Larry Garfield wrote:
>
>> I agree entirely. Setting reasonable expectations for users to plan around,
>> such as a known 5-years-per-major cycle, helps end users far more than
>> "whelp, we did something big
On 15 May 2023 19:38:56 BST, Larry Garfield wrote:
>Tangent: If I were to put together an RFC that set out such a 5 year cycle
>expectation with reasonable guidelines around when things could be deprecated,
>would anyone actually support it?
A big yes from me, but I've not had the most promisi
On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
> On 15 May 2023 09:54:41 BST, "G. P. B." wrote:
>
>>Why are we assuming that PHP 9.0 is going to come after PHP 8.4?
>
> Historically, PHP has had a major release roughly every five years. The
> main exception is PHP 6, which was never relea
On 15 May 2023 09:54:41 BST, "G. P. B." wrote:
>Why are we assuming that PHP 9.0 is going to come after PHP 8.4?
Historically, PHP has had a major release roughly every five years. The main
exception is PHP 6, which was never released - but whose major features became
PHP 5.3, five years after
On Sat, 13 May 2023 at 00:08, Larry Garfield wrote:
> That means it's impossible to write code that works from 8.2 to 9.0
> without version checks. The overlap period is only 2 releases (8.3 and
> 8.4). That's too short of a window.
>
Why are we assuming that PHP 9.0 is going to come after PHP
On 13 May 2023 00:08:22 BST, Larry Garfield
>A better argument, I think:
>
>The old function exists in 8.2, the new one does not.
>The new one exists in 8.3.
>The old one ceases to exist in 9.0.
>
>That means it's impossible to write code that works from 8.2 to 9.0 without
>version checks. The o
On Fri, May 12, 2023, at 9:59 PM, Rowan Tommins wrote:
> On 12 May 2023 19:17:20 BST, "Máté Kocsis" wrote:
>>Libraries have to
>>get rid of deprecated calls in any case, otherwise
>>their users will surely start to complain.
>
> I've said it before, and I'll say it again: the solution to this is
On 12 May 2023 19:17:20 BST, "Máté Kocsis" wrote:
>Libraries have to
>get rid of deprecated calls in any case, otherwise
>their users will surely start to complain.
I've said it before, and I'll say it again: the solution to this is not fewer
deprecation messages; it's better documentation to s
>
> So I would suggest rewording the options slightly:
>
> a) Deprecate in 8.3, remove in either 9.0 or 10.0
> b) Deprecate in 8.3, remove in 10.0
> c) Do not deprecate
>
> Now if the votes are a:5, b:4, c:4, we can say:
>
> - 9 people voted for deprecation in 8.3, vs 4 against
> - only 5 voted for
On Fri, May 12, 2023, at 6:52 AM, Rowan Tommins wrote:
> I think it's actually very likely that voters would want to express
> "deprecate, but do not remove before 10.0". Treating those votes as
> "generally in favour, so enough to approve removal in 9.0" doesn't seem
> appropriate.
>
> The oth
On 11 May 2023 18:06:44 BST, Dan Ackroyd wrote:
>On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote:
>>
>> I believe this vote format ("three options") is not really compatible
>> with the voting rules (https://wiki.php.net/rfc/voting).
>>
>> For example it's not entirely clear what would happen h
Hi Dan and Tim,
> The RFC author could just say that yes votes for deprecation and
> eventual removal will be added together, with the timescale being a
> preference vote.
>
Thank you, Dan, for the clarification, that was indeed what I meant. I'll
also
make this clear in the RFC, unfortunately
Hi
On 5/11/23 18:58, Dan Ackroyd wrote:
On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote:
Would it be an option to just deprecate everything in PHP 8.3
As I said before, having at least one version where the new versions
of the functions are available, and the old versions aren't giving
de
On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote:
>
> I believe this vote format ("three options") is not really compatible
> with the voting rules (https://wiki.php.net/rfc/voting).
>
> For example it's not entirely clear what would happen here:
>
> 5 votes to deprecate in 8.3 / remove 9.0
> 4 v
On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote:
>
> Would it be an option to just deprecate everything in PHP 8.3
As I said before, having at least one version where the new versions
of the functions are available, and the old versions aren't giving
deprecation notices, is the 'cleanest' way o
Hi
On 5/11/23 00:10, Máté Kocsis wrote:
If not, then we could just move really slowly on deprecating them. We
could deprecate them at some point in the 9.x release cycle and remove
them in 10.0.
Although I would love to get rid of as many overloaded signatures as
possible due to the above me
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#
Hi Dan (and Larry and Tim who responded to the same topic),
Would leaving the current versions in place and working actually cause
> any maintenance issues?
Yes, unfortunately they cause some maintenance issues: since they don't
have a single
signature, gen_stub.php generates the wrong signature
Hi Rowan,
> As an aside, I don't think "other deprecations are already more difficult"
> is a good argument - it's like saying "yes, I punched him, but not as hard
> as someone else already had". I think the change can be defended from other
> angles, but wanted to call that out.
>
I admit that
On Tuesday 02 May 2023 15:07:21 (+02:00), Rowan Tommins wrote:
> On Tue, 2 May 2023 at 13:20, Máté Kocsis wrote:
>
> > Yes, I agree that the assert_options() name is at least weird but I
> > wouldn't like to
> > include changes into this RFC which are not strictly related to overloaded
> > si
Hi
On 5/5/23 18:12, Derick Rethans wrote:
createFromIso8601(string $specification, int $options = 0)
-> createFromISO8601String
I am open to bike shedding about this :-)
Okay, I'd like a different color of my bikeshed:
Please no consecutive uppercase letters in the function name. I find
cre
On Thu, 27 Apr 2023, Máté Kocsis wrote:
> As you have possibly already experienced, overloaded signatures cause
> various smaller and bigger issues, while the concept is not natively
> supported by PHP. That's why I drafted an RFC which intends to phase
> out the majority of overloaded function
On Tue, May 2, 2023, at 5:05 PM, Tim Düsterhus wrote:
> Hi
>
> On 5/2/23 13:37, Dan Ackroyd wrote:
>> For the functions that are having new separate methods added, not
>> deprecating them immediately makes upgrading easier. When upgrading
>> from one version of PHP to the next, it is best if you ca
Hi
On 5/2/23 13:37, Dan Ackroyd wrote:
For the functions that are having new separate methods added, not
deprecating them immediately makes upgrading easier. When upgrading
from one version of PHP to the next, it is best if you can run the
same code on both versions, without any deprecation noti
On Tue, May 2, 2023, at 12:20 PM, Máté Kocsis wrote:
> As far as I see there are more deprecations which are easy to fix. In order
> to see the whole picture
> better, let's group the functions based on how a possible upgrade path
> would look like:
>
> - With existing suggested alternative:
>
On Tue, 2 May 2023 at 13:20, Máté Kocsis wrote:
> Yes, but changing session_set_save_handler() to session_set_save_handlers()
> should be a reasonably small effort, isn't it? I understand that it's
> going to affect
> lots of codebases, however other PHP 8.x deprecations are much more
> difficult
Hi Rowan,
As Kamil says, a potential 1-year deprecation is probably not enough,
> and we need to keep in mind that many libraries and applications need to
> support multiple versions of PHP at once. If they are to become errors
> in 9.0, there should be some way to write code that will run on both
Hi
On 5/2/23 13:56, Dan Ackroyd wrote:
And unless I'm missing something, the second option doesn't appear
usable with static methods, which is also a problem with
get_parent_class()
static::class or self::class appear to do the right thing depending on
what exactly you want to retrieve.
wh
On 27.04.2023 23:28, Máté Kocsis wrote:
https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
stream_context_set_option() should be removed from the Future Scope as
it already is being changed by the RFC.
--
Aleksander Machniak
Kolab Groupware Developer[https://kola
>From the RFC:
>
> Code which invokes get_class() without parameters should be modified to
> use __CLASS__ or get_class($this) instead,
I don't think the first option is equivalent:
class C {
function printType() {
echo "__CLASS__ is " . __CLASS__ . "\n";
echo "get_class is "
Kamil Tekiela wrote:
> > I think one year of deprecation is not enough... It doesn't make
> > sense to me to add a replacement but not deprecate the old variant.
Máté Kocsis wrote:
> Yes, this upgrade path also makes sense to me, and I'm happy to go with
> it if others don't disagree!
For the f
On Fri, 28 Apr 2023 at 09:16, Rowan Tommins wrote:
> On a different point, I think "assert_options" is a peculiar name for
> either setting or getting a single option, and would suggest it be
> replaced with two new functions, assert_get_option and
> assert_set_option.
>
Further to this, I've r
Hi Kamil,
Thank you for your reply, it is pretty much appreciated!
I think one year of deprecation is not enough. I believe the functions
> that get replacements should be deprecated immediately in PHP 8.3 to
> give people two years of deprecation notice. It doesn't make sense to
> me to add a re
On 27/04/2023 22:28, Máté Kocsis wrote:
As you have possibly already experienced, overloaded signatures cause
various smaller and bigger issues, while the concept is not natively
supported by PHP. That's why I drafted an RFC which intends to phase out
the majority of overloaded function/method si
Hi Máté,
I agree with this proposal, and I will be voting yes. The function
overloads are not a big issue for PHP developers, and some are very
much in use, but the reasons you listed are convincing and the manner
in which you propose to do it should create an easy upgrade path.
I think one year
Hi Internals,
As you have possibly already experienced, overloaded signatures cause
various smaller and bigger issues, while the concept is not natively
supported by PHP. That's why I drafted an RFC which intends to phase out
the majority of overloaded function/method signatures and also forbid
th
82 matches
Mail list logo
