Den ons. 3. maj 2023 kl. 04.43 skrev PHP Group :
> VCS Account Approved: ericmann approved by kalle \o/
Welcome aboard Eric!
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
VCS Account Approved: ericmann approved by kalle \o/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
PHP 8.3 release management
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
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
14 matches
Mail list logo
