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
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,
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
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()
*
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()
>
> > > 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
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
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:
> > >
> > >
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,
> >
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
>
> > 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
> >
>
> 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
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
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,
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
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
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
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
>>
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
> 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
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 (
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
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
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
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
> 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
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
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
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
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
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
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
>
> 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
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
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
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
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
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
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
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:
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
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
> >
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
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
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
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
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
>
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
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.
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
>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
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
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
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
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
63 matches
Mail list logo
