Re: [PHP-DEV] [RFC] Interface Default Methods

[Alexandru Pătrănescu]

On Tue, Jun 20, 2023 at 7:30 AM Levi Morrison  wrote:

> On Sat, Jun 17, 2023 at 6:05 AM Alexandru Pătrănescu 
> wrote:
> >
> > 1. Do we want to allow also private methods in the interface so that it
> > allows code reuse or better code organization in smaller methods?
>
> Sorry for the delay in responding to your message. I have implemented
> support for private methods for people to experiment with. As far as I
> can tell, it works as expected and I don't see any issues with them.
> Of course, they only make sense as helper methods to the public
> default methods.
>

> I'd like to hear what others think about allowing private interface
> methods that have method bodies, but I think it's easy and sensible.
>

Looks good to me. Thank you!


>
> > Would a method implemented by a trait have higher precedence over the
> > interface default implementation?
> > Would a trait offered implementation be directly usable by the interface?
>
> I'm not entirely sure what you are asking about traits, so I'll try to
> clarify. In a class which uses a trait to implement an interface, that
> trait method will take priority over the interface's default method. I
> will add a test to the PR to make this more obvious.
>

Yes, that looks good, this was the first question, exactly.


Sorry for the lack of clarity in my second question.
Is it if it would be allowed to have something like:

trait Trait1 {
function method1() { echo __METHOD__, "\n"; }
}

interface Interface1 {
use Trait1;
function method1();
}

So both trait and interface can be used independently without code
duplication.

A more complex scenario where this might be useful:

// external package
interface Interface1 {
function method1();
}
interface Interface2 {
function method2();
}

// internal package
trait Trait1 {
function method1() { echo __METHOD__, "\n"; }
}
trait Trait2 {
function method2() { echo __METHOD__, "\n"; }
}
interface Interface3 extends Interface1, Interface2 {
use Trait1;
use Trait2;
}

Where it will allow either usage of a class for:
- Interface1 with Trait1
- Interface2 with Trait2
- Interface3 that would already have the method implemented.

Hope it's clearer now.
I don't know if we want to support use of a trait in the interface
but I think the RFC should mention that it is or is not supported.

Thank you,
Alex

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison]

On Sat, Jun 17, 2023 at 6:05 AM Alexandru Pătrănescu  wrote:
>
> Thank you for this!
> I like the proposal and I think it fits well.
> I'm used to it from Java and I don't know any reason for it to be
> considered a bad practice since it was introduce, about 9-10 years ago.
>
> 1. Do we want to allow also private methods in the interface so that it
> allows code reuse or better code organization in smaller methods? Java
> introduced this only in the next version.
> The private methods would be invisible to implementing classes and to
> anything else, of course.
> We can also add them at a later point but it might be better to have the
> feature complete now.
>
> Sidenote: I don't think protected method should ever exist on interfaces;
> that should remain for abstract classes use case.

Sorry for the delay in responding to your message. I have implemented
support for private methods for people to experiment with. As far as I
can tell, it works as expected and I don't see any issues with them.
Of course, they only make sense as helper methods to the public
default methods.

I'd like to hear what others think about allowing private interface
methods that have method bodies, but I think it's easy and sensible.

> 2. The only use case for myself for ever using traits would be if traits
> would offer a default implementation for an interface. Now with a default
> implementation offered by interface itself, sounds even better.
> However, I can see how there could be more than one provided default
> implementation that can be offered.
> Would a method implemented by a trait have higher precedence over the
> interface default implementation?
> Would a trait offered implementation be directly usable by the interface?

I'm not entirely sure what you are asking about traits, so I'll try to
clarify. In a class which uses a trait to implement an interface, that
trait method will take priority over the interface's default method. I
will add a test to the PR to make this more obvious.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

[Juliette Reinders Folmer]

On 19-6-2023 23:27, Máté Kocsis wrote:

Hi Juliette,

For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").

For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other RFCs that add
new features,
because functionality usually is deprecated because it is "harmful" in one
way or another. A large impact (i.e. broad usage) should not necessarily be
an
argument against deprecation. Please also keep in mind that a deprecation
is just that, a deprecation. It gives developers a heads up to migrate off
the
functionality at their own pace. We know that package maintainers are
bugged by users whenever a new deprecation message emerges in a new PHP
version,
but this doesn't mean maintainers must react right away.

Let us elaborate why we don't think impact analysis is needed here:

* As per the TYPE_CURRENCY constant is (a) completely non-functional and
(b) unfixable. As such any code that uses the constant is already broken and
the deprecation is just pointing this out, making the user aware.
* The CRYPT_* constants are possibly the least harmful part of the RFC, but
they still can be misleading to a new developer. They are trivially
polyfilled and
also trivially removed from existing code by replacing them with 1.
* MT_RAND_PHP is broken, because the sequences are not well-defined,
defeating any reason for seeding. More reasons are already given in the RFC.
* mt_rand() is everywhere and we don't believe anyone is denying that fact.
But this should not be a reason against deprecation. As the RFC outlines,
it is trivial to find this function misused with GitHub's search. We
believe that the depreciation benefit outweighs the costs for existing
users.
* ldap_connect() is already soft-deprecated in the documentation.

Regards,
The authors of th RFC



Hi Máté,

While I appreciate that _most_ of these will be low impact and are 
justified, I very much disagree with that for the proposed `mt_rand()` 
and friends deprecations.


There are plenty of situations where it is of absolutely no interest to 
get a crypographically secure value, like for generating some 
semi-random test data and I strongly believe the impact of these 
deprecations to be large and fixing it won't always be trivial for 
codebases which support a range of PHP versions.


As a matter of principle I believe there should be an impact analysis 
for anything being deprecated. It can inform the voters as to the 
appropriateness of the timing of the deprecation - early on in a major 
cycle vs late in a major cycle -. Others may just take it as a FYI, but 
at least they have access to the information if they wanted to assess it.


While I appreciate what you are saying about deprecations being an 
"action list to migrate at your own pace", the reality for open source 
packages is different as the sheer amount of deprecations over the past 
few years have taken huge amounts of time to address and "leaving those 
till later" is just not an option as the amount of time needed is the 
same and time can only be spend once.


To give you some idea: work related to PHP 8.0 and 8.1 has been nine 
months out of the year for each in my case for the open source projects 
I'm involved with, so no, leaving that to later is not an option.


Smile,
Juliette

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Juliette Reinders Folmer]

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()
* ReflectionProperty::setValue()


These are intentionally left out due to different reasons:

* Even though the 1 parameter version of array_keys() is used a lot, its 2+
parameter signature is much less known.
Personally, I've never used it. Of course, this doesn't mean no one uses
it, but I don't think this deprecation will really
matter in practice, so I didn't care to write a script for this (the rest
of the deprecations were easy to analyze via regexes).

* ReflectionProperty::setValue() would be a lot of work to analyze since
it's very difficult to track whether the
setValue() method is called on a ReflectionProperty instance. Not to
mention the fact that the deprecation only affects
function invocations where either a single parameter is provided or static
properties where the first parameter is not null
or an object instance. Since the suggested alternative is basically
available since forever, I think it's OK not to do
an exhaustive analysis in this case.



For the `get*_class()` deprecation, I wonder if an additional impact
analysis is needed for packages which may not have removed usages of
`get_class( null )`, which would now be double-impacted (and not caught
by the current analysis).


I'm not sure I can follow you, but get_class(null) is a TypeError since 8.0
(and have been warning since 7.2). If a package
didn't feel the need to migrate its get_class() usages then it is likely a
dead project. And if someone tries to upgrade their
(proprietary) code from PHP 7.1 to PHP 8.3 directly then they will notice
the exception first and also - if they followed the upgrading
notes carelly - will learn the relevant suggestions regarding the
deprecation. But realistically speaking, these projects will most probably
be bound by lots of other more severe issues, so I don't think the above is
a viable upgrade path...

Regards,
Máté


Thanks for the reply Máté.

I understand what you are saying and appreciate it may be difficult to 
get an accurate impact analysis for `ReflectionProperty::setValue()`.


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 could take that stench away ?


Smile,
Juliette

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison]

> I like the idea of this RFC - in fact it's one which has been near top of
> my wishlist for PHP language features for a long time - but I think this is
> an issue with the proposed implementation which at the very least warrants
> highlighting and discussion.

I understand your concern but personally believe it's overblown. This
problem already exists with abstract classes, but doesn't seem to be
that much of an issue in practice. I hope static analysis can fill the
gap here, but don't think these checks are necessary to ship this
feature.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

[Máté Kocsis]

Hi Juliette,

For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").

For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other RFCs that add
new features,
because functionality usually is deprecated because it is "harmful" in one
way or another. A large impact (i.e. broad usage) should not necessarily be
an
argument against deprecation. Please also keep in mind that a deprecation
is just that, a deprecation. It gives developers a heads up to migrate off
the
functionality at their own pace. We know that package maintainers are
bugged by users whenever a new deprecation message emerges in a new PHP
version,
but this doesn't mean maintainers must react right away.

Let us elaborate why we don't think impact analysis is needed here:

* As per the TYPE_CURRENCY constant is (a) completely non-functional and
(b) unfixable. As such any code that uses the constant is already broken and
the deprecation is just pointing this out, making the user aware.
* The CRYPT_* constants are possibly the least harmful part of the RFC, but
they still can be misleading to a new developer. They are trivially
polyfilled and
also trivially removed from existing code by replacing them with 1.
* MT_RAND_PHP is broken, because the sequences are not well-defined,
defeating any reason for seeding. More reasons are already given in the RFC.
* mt_rand() is everywhere and we don't believe anyone is denying that fact.
But this should not be a reason against deprecation. As the RFC outlines,
it is trivial to find this function misused with GitHub's search. We
believe that the depreciation benefit outweighs the costs for existing
users.
* ldap_connect() is already soft-deprecated in the documentation.

Regards,
The authors of th RFC

Re: [PHP-DEV] Possible RFC: PDOStatement::addBatch

[mickmackusa]

So if I'm not missing something, you want to add this new method to core to
accommodate situations where:

1. the dev is too inexperienced to implement a pre-existing library and
2. the incoming 2d payload is not packaged as a csv file (and therefore
cannot be directly imported as such) and
3. the application does not benefit from accessing the auto-incremented ids
generated by each insert and
4. the performance of the bulk insertions resolves a crippling bottleneck
in performance?

IMO, the total footprint of your implemented snippet isn't significantly
"sleeker/sexier" than using concatenation.  I don't see anything ugly or
unreadable about building two flat arrays, then using them to construct a
SQL string and feed the execute() method. https://phpize.online/s/iW

I am not an RFC voter, but I don't really see a compelling reason to add
this method to the language.

mickmackusa

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Máté Kocsis]

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()
>

These are intentionally left out due to different reasons:

* Even though the 1 parameter version of array_keys() is used a lot, its 2+
parameter signature is much less known.
Personally, I've never used it. Of course, this doesn't mean no one uses
it, but I don't think this deprecation will really
matter in practice, so I didn't care to write a script for this (the rest
of the deprecations were easy to analyze via regexes).

* ReflectionProperty::setValue() would be a lot of work to analyze since
it's very difficult to track whether the
setValue() method is called on a ReflectionProperty instance. Not to
mention the fact that the deprecation only affects
function invocations where either a single parameter is provided or static
properties where the first parameter is not null
or an object instance. Since the suggested alternative is basically
available since forever, I think it's OK not to do
an exhaustive analysis in this case.


> For the `get*_class()` deprecation, I wonder if an additional impact
> analysis is needed for packages which may not have removed usages of
> `get_class( null )`, which would now be double-impacted (and not caught
> by the current analysis).
>

I'm not sure I can follow you, but get_class(null) is a TypeError since 8.0
(and have been warning since 7.2). If a package
didn't feel the need to migrate its get_class() usages then it is likely a
dead project. And if someone tries to upgrade their
(proprietary) code from PHP 7.1 to PHP 8.3 directly then they will notice
the exception first and also - if they followed the upgrading
notes carelly - will learn the relevant suggestions regarding the
deprecation. But realistically speaking, these projects will most probably
be bound by lots of other more severe issues, so I don't think the above is
a viable upgrade path...

Regards,
Máté

Re: [PHP-DEV] [RFC] Interface Default Methods

[David Gebler]

On Mon, Jun 19, 2023 at 9:53 PM Rowan Tommins 
wrote:

> On 19/06/2023 20:20, David Gebler wrote:
> > Okay, thanks. That's really quite significant, since it changes the
> feature
> > to one which could allow changes made to interfaces to adversely impact
> > existing clients of an interface without those clients changing a thing.
>
>
> As the RFC says, it introduces a form of multiple inheritance, and
> inheritance in PHP doesn't make any such guarantee - to adapt your example:
>
> class A {
>  public function foo(): void {
>  $this->bar();
>  }
> }
>
> class B extends A {
>  public function bar(): void {
>  ...
>  }
> }
>
> The job of detecting that class A doesn't define a contract for method
> bar falls to static analysers, and the same would be true for default
> implementations on interfaces.
>
>
>
>
Sure, but in this example were B::bar() to be a private method, you would
get a scope violation error. You would not if you were to use a trait,
since any methods implemented in the trait would be executed in the same
scope as the class using the trait. And that seems to be what's being
proposed here for interface defaults. So my concern here is that when you
use a trait, you know that what you're doing is effectively
copy-and-pasting implementation into your class scope. You don't expect
that when you declare a class to implement an interface.

There's some degree of irony to me that we have another RFC, the Override
attribute, which will introduce an engine-level check that could easily
(and arguably should) be left to static analysis tools, yet we're talking
here about introducing a mechanism where private methods on a class could
be called by stealth by a mere interface. I'm not even sure static analysis
tools would in their typical configuration pick up on a situation like
this, either, since it could in this scenario sit in a vendor dependency
and not your own code.

I like the idea of this RFC - in fact it's one which has been near top of
my wishlist for PHP language features for a long time - but I think this is
an issue with the proposed implementation which at the very least warrants
highlighting and discussion.

Re: [PHP-DEV] [RFC] Interface Default Methods

[Rowan Tommins]

On 19/06/2023 20:20, David Gebler wrote:

Okay, thanks. That's really quite significant, since it changes the feature
to one which could allow changes made to interfaces to adversely impact
existing clients of an interface without those clients changing a thing.



As the RFC says, it introduces a form of multiple inheritance, and 
inheritance in PHP doesn't make any such guarantee - to adapt your example:


class A {
public function foo(): void {
$this->bar();
}
}

class B extends A {
public function bar(): void {
...
}
}

The job of detecting that class A doesn't define a contract for method 
bar falls to static analysers, and the same would be true for default 
implementations on interfaces.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Rowan Tommins]

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 signatures, so what does making it the preferred signature (with 
users of the other having to change their code) have to do with 
"history/legacy"?



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Nicolas Grekas]

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
> > equally OK to force anyone using an object to change their code?
> >
>
> As far as I remember, my reasoning was two-fold:
> - naming: passing *multiple* callbacks to a function name in singular
> (session_set_save_handler())
> is definitely not ideal
> - a decision had to be made and I thought that keeping the OO approach in
> place had less BC impact,
> especially because previously I got feedback from Nicolas that they used
> this version.
>
>
> > I do wonder if this change is too disruptive relative to the benefit it
> > brings, but in that case, we should just leave the whole function as it
> is.
> >
>
> In my opinion, phasing out session_set_save_handler() completely would be
> worth the effort if this
> was the only option to fix the overridden signature. However, it's not the
> case, since strictly speaking,
> only one of the two signatures has to be removed in order to achieve the
> desired goal of the RFC.
> 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. All
> in all, I think neither not doing
> anything, nor deprecating the whole function is a good choice. But at least
> I definitely want the question
> to be settled with putting this to vote.
>
> I don't think "handler" particularly implies "object". The "handler" passed
> > to set_error_handler is a function, and your original suggestion for a
> new
> > function was "session_set_save_handlers", where "handler" would also mean
> > "function".
> >
>
> Without any suffix at all, it seems like "set a session handler the normal
> > way" vs "set a session a special different way"; like how
> > "array_merge_recursive" is a special version of "array_merge".
> >
>
> I think my reasoning is easier to understand if we go back to my original
> suggestion:
> session_set_save_handler() and session_set_save_handlers(), which would be
> session_set_handler() and session_set_handlers() now. That was the starting
> point,
> but you didn't like that they only differ by an "s". That's why I swapped
> the "s" with "callbacks".
>
> According to your deduction, session_set_handler() is not the most correct
> name indeed, but I don't think
> that we always have to choose the most correct and the entirely descriptive
> one. After all, neither the
> parameters of session_set_handler() are called "$open_callback",
> "$close_callback" etc., they are just
> "$open", "$close" etc. and I guess they are still clear enough, given that
> their type is declared which
> completes the missing context.
>
> Similarly, we all would know that the session_set_handler() function
> expects an object of
> SessionHandlerInterface type, while its sibling,
> session_set_handler_callbacks()  expects some
> callbacks. Yes, having the _object suffix is the most pedantic name, but
> personally, I don't really like it
> because I find it ugly (and I was pretty much content with
> session_set_handlers()). I'm curious about
> the point of view of other people though, because if it turns out that
> people generally also favor some
> other name then I'm ok with a compromise.
>


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.
And I don't think we should alias this function to a new name because that
would require users to make a choice, and will lead to confusion, because
in this case, the choice is purely cosmetic, but people will still have to
get it.

Nicolas

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Nicolas Grekas]

> > > 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 $options = 0)
> > > → createWithRange(DateTimeInterface $begin, DateTimeInterface $end,
> > > DateTimeInterface $int, int $options = 0)
> > >
> > > createFromRecurrences(DateTimeInterface $start, DateInterval $interval,
> > > int $recurrences, int $options = 0)
> > > → createWithRecurrences(DateInterval $begin, int $recurrences,
> > > DateInterval $interval, int $options = 0)
> > >
> > > We also should fix the argument names. Either $start/$finish, or
> > > $begin/$end. I
> > > prefer the latter.
> > >
> > > createFromIso8601(string $specification, int $options = 0)
> > > -> createFromISO8601String
> > >
> > > I am open to bike shedding about this :-)
> > >
> >
> > 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 still has an overloaded third argument — DateTimeInterface|int.
>
Where you trying to suggest to change the current existing __construct()
> to:
>
> public function __construct(DateTimeInterface $start, DateInterval
> $interval, DateTimeInterface $end, int $options = 0)
>
> and then add these two new factory methods?
>
> createFromRecurrences(DateTimeInterface $start, DateInterval $interval,
> int $recurrences, int $options = 0)
>
> createFromISO8601String(string $specification, int $options = 0)
>

I really meant DateTimeInterface|int, not an overloaded signature but a
union type.

My concern is about providing the best path forward.
Both deprecating and providing the alternative in the same version creates
a lot of friction for end users.
After a quick chat with Mate, I think we should do this union type *in
addition* to adding the new static constructors.
Then, later on, if future us think it's worth it, we might want to consider
deprecating passing an integer.
This would provide a path for BC/FC I would fully support.

Nicolas

Re: [PHP-DEV] [RFC] Interface Default Methods

[David Gebler]

On Mon, Jun 19, 2023 at 3:53 AM Levi Morrison 
wrote:

>
> No, there's no attempt to ensure the method body adheres to calling
> the public interface. Due to PHP's possible dynamic behaviors, I don't
> think it's reasonable to attempt to enforce it at compile-time. I'm
> not sure it's worth the effort trying to enforce it at runtime either,
> but it would be nice to see lints from static analysis tools which
> detect this issue.
>

Okay, thanks. That's really quite significant, since it changes the feature
to one which could allow changes made to interfaces to adversely impact
existing clients of an interface without those clients changing a thing.

I was excited by the description of the RFC, but I was imagining something
more like how Java does it. Personally, this limitation (or rather lack of
it) is enough that I wouldn't support it and I'd urge anyone who can vote
to carefully consider the implications of the implementation being proposed.

[PHP-DEV] Re: [RFC] [VOTE] mb_str_pad

[Niels Dossche]

On 05/06/2023 19:59, Niels Dossche wrote:
> Hello internals
> 
> I'm opening the vote now on my proposal to include mb_str_pad() into PHP 8.3.
> RFC link: https://wiki.php.net/rfc/mb_str_pad
> 
> The vote will last until 2023-06-19 20:00 GMT+2.
> 
> Kind regards
> Niels

Hi internals

The voting is now closed with 15 yes and 1 no vote.
The RFC is therefore accepted.
Thanks to everyone who voted.

Kind regards
Niels

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Request to create a RFC for const args

[Olle Härstedt]

2023-06-19 12:59 GMT+02:00, Sam McDonald :
> He6 Olle,
> Yes more so the former, not the latter in your example.
> If there is already an rfc in place then that is fantastic.
> Regards
> SAM

There's no RFC, just me mailing out the idea when I had it. :) Go wild.

Olle

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Expired pear.php.net certificates

[Timo Tijhof]

It appears to have been resolved after 13 hours, as of 45min ago.

pear.php.net. Let's Encrypt.
Valid Not Before: Mon, 19 Jun 2023 10:11:33 GMT

-- Timo


On Sun, Jun 18, 2023 at 10:46 PM jocelyn fournier <
jocelyn.fourn...@gmail.com> wrote:

> Hi!
>
> FYI, it seems pear.php.net  https certificate
> expired today:
>
> ERROR: The certificate of ‘pear.php.net’ is not trusted.
> ERROR: The certificate of ‘pear.php.net’ has expired.
> The certificate has expired.
>
> (confirmed by checking it using a browser)
>
> BR,
>   Jocelyn Fournier
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Request to create a RFC for const args

[Sam McDonald]

He6 Olle,
Yes more so the former, not the latter in your example.
If there is already an rfc in place then that is fantastic.
Regards
SAM

Sent from Outlook for Android

From: Olle Härstedt 
Sent: Monday, June 19, 2023 7:47:49 PM
To: Sam McDonald 
Cc: internals@lists.php.net 
Subject: Re: [PHP-DEV] Request to create a RFC for const args

2023-06-19 9:56 GMT+02:00, Sam McDonald :
> Hello php internals team,
> I would like to put forward an RFC for a new feature. I am a long time user,
> but have never participated as yet to the RFC.
>
> This is my first step to gather reaction/feedback from the team.
>
> I would be happy to implement the feature and post a PR or have someone from
> the team implement this.
>
> The feature I want to put forward is "const function arguments" (same for
> methods)
>
> This feature is available in cpp, and I believe would be a benefit to the
> php community.
>
> My RFC would fully detail and clarify what this is and how it works.
>
> This feature allows the user to specify "const" on a function arg, so that
> the argument while in a function can not be reassigned.
>
> The following example would throw an exception at compile/runtime.
>
> ```
> public function foo(const int $bar)
> {
>$bar =3D "buz";
> }
> ```

Isn't this similar to my own idea of readonly function arguments?
https://externals.io/message/120203#120210

Perhaps more limited in scope?

Olle

Re: [PHP-DEV] Request to create a RFC for const args

[Olle Härstedt]

2023-06-19 9:56 GMT+02:00, Sam McDonald :
> Hello php internals team,
> I would like to put forward an RFC for a new feature. I am a long time user,
> but have never participated as yet to the RFC.
>
> This is my first step to gather reaction/feedback from the team.
>
> I would be happy to implement the feature and post a PR or have someone from
> the team implement this.
>
> The feature I want to put forward is "const function arguments" (same for
> methods)
>
> This feature is available in cpp, and I believe would be a benefit to the
> php community.
>
> My RFC would fully detail and clarify what this is and how it works.
>
> This feature allows the user to specify "const" on a function arg, so that
> the argument while in a function can not be reassigned.
>
> The following example would throw an exception at compile/runtime.
>
> ```
> public function foo(const int $bar)
> {
>$bar =3D "buz";
> }
> ```

Isn't this similar to my own idea of readonly function arguments?
https://externals.io/message/120203#120210

Perhaps more limited in scope?

Olle

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Request to create a RFC for const args

[Sam McDonald]

Hello php internals team,
I would like to put forward an RFC for a new feature. I am a long time user, 
but have never participated as yet to the RFC.

This is my first step to gather reaction/feedback from the team.

I would be happy to implement the feature and post a PR or have someone from 
the team implement this.

The feature I want to put forward is "const function arguments" (same for 
methods)

This feature is available in cpp, and I believe would be a benefit to the php 
community.

My RFC would fully detail and clarify what this is and how it works.

This feature allows the user to specify "const" on a function arg, so that the 
argument while in a function can not be reassigned.

The following example would throw an exception at compile/runtime.

```
public function foo(const int $bar)
{
   $bar =3D "buz";
}
```

The same for complex types such as arrays and classes, if a 'const' arg is 
provided, while in the function it can not be reassigned.

Please let me know if this is something the team is interested in and if I 
should proceed.

Kind regards.
Sam McDonald.


Sent from Outlook for Android