Re: [PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

[Alexandru Pătrănescu]

On Fri, Aug 27, 2021 at 12:53 AM Rowan Tommins 
wrote:

> On 26 August 2021 21:20:35 BST, "Olle Härstedt" 
> wrote:
> >The Foo class has to decide who to give access to, otherwise it's the
> >same as public access.
>
>
> It does decide who has access: any class that declares it as "delegated".
> In exactly the same way, "protected" gives access to any class that
> declares it as a "parent", and namespace visibility would give access to
> any class that declares itself in the same namespace.
>
> None of those actually limit access to a named list of classes, but all of
> them document an intended use, and catch mistakes where that intent isn't
> followed.
>

Well I wouldn't say they're quite the same. You can definitely limit the
usages more with the "private" keyword. Or with declaring the class "final"
for "protected" visibility, not allowing a "parent".
I think something along these lines was asked. To have a way to decide the
limitation by the original library, not by the one that decides to use it.

Now... I also think that we might not necessarily need this.
So far it looks like @internal works well enough.
If a library is marking a class or method with @internal, it means it is
not part of the public API and they might change it in the future.

Static tool analysis like phpstan and psalm produce errors for using it.
Also editors will warn you if you are using it.
For all purposes you should treat it as private.

If we really want the PHP runtime to produce a warning/error, even if this
check makes sense mostly statically, we can think about a similar metadata
with attributes with something like
#[PackageInternal(namespacePrefix: 'Acme\Foo')]
that can be applied to methods, classes and even properties and would
trigger those warnings/errors when used from another namespace.

This leaves the decision point on the library authors, not on the users of
it.

Regards,
Alex


>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Mike Schinkel]

> On Aug 26, 2021, at 11:02 PM, Pierre Joye  wrote:
> I don't know how others feel about it, I think most want to go the
> path to (2) and a more strict, if not almost fully strict PHP. Core
> devs to simplify the engine, users to allow them easier checks and
> safety in their frameworks or libs. End user don't really bother as
> far as I can see. We may have to decide once the long term vision for
> PHP and then do the changes accordingly, and more importantly, with
> consistency.

I tend to concur that path (2) would provide the better outcome. 

However, eliminating dynamic variables would be eliminating the ability to 
simulate a(t least one) language feature that some (many?) people have been 
using dynamic variables to simulate. Maybe as part of deprecation of dynamic 
variables we should also consider adding this(ese) feature(s) to the PHP 
language?

There are two approaches I can envision, Both would better enable the 
S.O.L.I.D. "open-closed" principle in PHP.  

1.) Allow PHP class declaration across multiple files — A use-case for this is 
what I think is effectively the command dispatcher pattern where properties 
contain instances of classes that might be contributed by 3rd party code to 
allow those developers to access the instances by named property: e.g. 
$cms->map->display() where $map is added by a 3rd party library to the class 
for the $cms instance before $cms is instantiated.  See:

https://gist.github.com/mikeschinkel/ed4f9594c105dae7371bfce413399948

Some might view this as "monkey patching" but I view it as a more structured 
approach, like C# partial classes.

2.) Allow trait usage for a class from another file — This is just a slightly 
different spin on #1. See:

https://gist.github.com/mikeschinkel/5b433532dc54adf53f5b239c8086fd63

Each approach has its own pros and cons but it probably depends on which would 
be easier and more performant to implement.

-Mike

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Tobias Nyholm]

Just giving my 2 cents: 

> 2. Remove support for dynamic properties entirely. 

I support this RFC and I like the end goal to be to remove the dynamic 
properties entirely. 

Dynamic properties are just confusing for beginners. “This is how you declare 
properties, the scope, the type, name etc.. but you don’t have too…”
I also remember that I’ve fixed more than one bug because I misspelled a 
property name. 

I understand there will be an impact on legacy code but there is help to find 
dynamic properties (static analysers) and there is also a clear upgrade path. 

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Pierre Joye]

Hi Stan,

On Fri, Aug 27, 2021 at 5:10 AM Stanislav Malyshev  wrote:
>
> Hi!
>
> > The crux of the issue is what our end goal is:
> >
> > 1. Require users to explicitly annotate classes that use dynamic
> > properties, but otherwise keep dynamic properties as a fully supported part
> > of the core language.
> > 2. Remove support for dynamic properties entirely. The core language only
> > has declared properties and __get/__set, and nothing else. stdClass is just
> > a very efficient implementation of __get/__set.
>
> I think goal (1) is reasonable for the long run, and goal (2) is taking
> it a bit too far for PHP.

I feel the same way. However my gut feeling tells me that we will end
up with (2) sooner or later. Having StdClass behaving differently
(even if it is technically not, I don't think the "it is a more
efficient get/set implementation" will make it through our users base)
looks inconsistent.

I don't know how others feel about it, I think most want to go the
path to (2) and a more strict, if not almost fully strict PHP. Core
devs to simplify the engine, users to allow them easier checks and
safety in their frameworks or libs. End user don't really bother as
far as I can see. We may have to decide once the long term vision for
PHP and then do the changes accordingly, and more importantly, with
consistency.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Matthew Brown]

On Thu, 26 Aug 2021 at 21:20, Sara Golemon  wrote:

> We're
> going to need to run some static analyzers on some frameworks and
> libraries.  Who's got it in them to do the research?
>
> -Sara
>

I'm not volunteering, but I forked Nikita's package analysis to add Psalm
scanning a while ago: https://github.com/muglug/popular-package-analysis

It's not trivial (downloading the requisite files takes up a lot of HDD
space) but Psalm's output can be parsed and analysed looking for
UndefinedPropertyFetch and UndefinedThisPropertyFetch issues.

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Sara Golemon]

On Thu, Aug 26, 2021 at 3:34 AM Nikita Popov  wrote:
>
> The crux of the issue is what our end goal is:
>
> 1. Require users to explicitly annotate classes that use dynamic
properties,
> but otherwise keep dynamic properties as a fully supported part of the
core language.
>
That's how I initially read your RFC, what I'm hearing here is that your
quite explicit goal is:

> 2. Remove support for dynamic properties entirely. The core language only
has
> declared properties and __get/__set, and nothing else. stdClass is just a
very
> efficient implementation of __get/__set.
>
If that's your position, then the `extends stdClass` approach makes sense,
because the dynamic properties HashTable can live in the object's extra
data offset block and the get_prop/set_prop implementations in stdClass'
handlers are the *only* things which know about dynamic properties.  That
represents a significant advantage to the engine for the "happy path" of
declared properties only.  Every (non-dynamic) object is a word (8 bytes)
leaner, and the branch points for dynamic property access are limited to
the only place they can be used, and where the typical result is positive.

Starting from that argument, your RFC begins to look more compelling.  I
was definitely not starting there on an initial read.

I do still have reservations about enforcing stdClass as a root for any
class which wants to use dynamic properties.  It's messy, but... to
paraphrase what you said about going with an attribute approach... yeah,
someone could make every current root class in their application explicitly
inherit from stdClass without any ill effects in PHP < 8.2, with only the
exception of external libraries being a problem.

So that's the spectrum:
- Opt-in to strict behavior: No BC impact, least benefit to the ecosystem
or the engine
- Attribute/Interface opt-out (goal#1): Moderate BC impact, ecosystem
benefits well, engine benefits a little, but not much.
- Extend stdClass opt-out (goal#2): Highest BC impact, ecosystem and engine
benefit most.

Goal#2 is bold.  Possibly not-too-bold, but it's not clear to me where
dynamic props are being used today and how many of those places can't "just
extend stdClass" for one reason or another.

Goal#1 might be a stepping stone along the way to Goal#2, as it will give
us something clear to scan for across major frameworks at the very least,
but that is going to push us from removal in 9.0 all the way out to removal
in 10.0.  If you're keeping track, that's gonna be circa 2030 give or take
a year or two.  That might be dangling the carrot out a little too far...

The purist in me wants to be bold.  It also wants some hard data on
existing usages.  A simple grep isn't going to cut it this time.  We're
going to need to run some static analyzers on some frameworks and
libraries.  Who's got it in them to do the research?

-Sara

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Stanislav Malyshev]

Hi!


The crux of the issue is what our end goal is:

1. Require users to explicitly annotate classes that use dynamic
properties, but otherwise keep dynamic properties as a fully supported part
of the core language.
2. Remove support for dynamic properties entirely. The core language only
has declared properties and __get/__set, and nothing else. stdClass is just
a very efficient implementation of __get/__set.


I think goal (1) is reasonable for the long run, and goal (2) is taking 
it a bit too far for PHP.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

[Rowan Tommins]

On 26 August 2021 21:20:35 BST, "Olle Härstedt"  wrote:
>The Foo class has to decide who to give access to, otherwise it's the
>same as public access.


It does decide who has access: any class that declares it as "delegated". In 
exactly the same way, "protected" gives access to any class that declares it as 
a "parent", and namespace visibility would give access to any class that 
declares itself in the same namespace.

None of those actually limit access to a named list of classes, but all of them 
document an intended use, and catch mistakes where that intent isn't followed.

Regards,

-- 
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

[Olle Härstedt]

2021-08-26 22:20 GMT+02:00, Olle Härstedt :
> 2021-08-26 20:30 GMT+02:00, Rowan Tommins :
>> On 26/08/2021 14:47, Olle Härstedt wrote:
>>> Don't know if this already exists, but maybe we could consider
>>> brainstorming or gather alternatives for different types of
>>> encapsulation when using composition?
>>
>>
>> Although not quite equivalent to your suggestions, these threads on
>> making delegation to an encapsulated object might be interesting to you:
>>
>> *  https://externals.io/message/103353
>> * https://github.com/php/php-src/pull/5168
>
> Right, there are indeed a bunch of attempts and suggestions, some
> downvoted, others abandoned.
>
> I'm thinking adding namespaces to runtime might be a logical first
> step. That would allow attributes to add logic like internal
> properties for a certain namespace. Makes me wonder why that never
> happened for this PR: https://github.com/php/php-src/pull/947
>
> Asking anyone on the list, would it be possible to make an opcode out
> of "namespace Foo\Bar" and letting it set a flag in the runtime system
> when run? Then make the flag accessible with a constant like
> __NAMESPACE_RUNTIME__ or whatever.
>
> Ooooh, there's an interesting case with "goto" and namespace
> visibility here:
> https://github.com/php/php-src/pull/947#issuecomment-419821198
>
> That would mean every zval has to carry in which namespace it was
> defined inside. I wonder how that would affect the memory footprint of
> PHP.
>
>> If we had something like that, then perhaps there could be a
>> "delegatable" visibility, which was the equivalent for "protected", but
>> when delegating rather than inheriting, e.g.
>>
>> class Foo {
>>  private int $a = 1;
>>  delegatable int $b = 2;
>> }
>>
>> class Bar {
>>  private delegate Foo $foo;
>>  public function __construct(Foo $foo) {
>>  $this->foo = $foo;
>>  echo $this->a; // Error: can't access private property of a
>> different class
>>  echo $this->b; // allowed: access is to a "delegatable"
>> property, in a "delegated" context
>>  }
>> }
>
> The Foo class has to decide who to give access to, otherwise it's the
> same as public access.
>
> Olle

Whops, Nikic already answered this in 2016:

> The goto here will jump from code in namespace A to code in namespace B 
> without "directly" crossing the boundary. For this reason just inserting 
> opcodes when a namespace starts or ends will quite cut it.

https://github.com/php/php-src/pull/947#issuecomment-224934615

So, deprecate goto when...?

Olle

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

Re: [PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

[Olle Härstedt]

2021-08-26 20:30 GMT+02:00, Rowan Tommins :
> On 26/08/2021 14:47, Olle Härstedt wrote:
>> Don't know if this already exists, but maybe we could consider
>> brainstorming or gather alternatives for different types of
>> encapsulation when using composition?
>
>
> Although not quite equivalent to your suggestions, these threads on
> making delegation to an encapsulated object might be interesting to you:
>
> *  https://externals.io/message/103353
> * https://github.com/php/php-src/pull/5168

Right, there are indeed a bunch of attempts and suggestions, some
downvoted, others abandoned.

I'm thinking adding namespaces to runtime might be a logical first
step. That would allow attributes to add logic like internal
properties for a certain namespace. Makes me wonder why that never
happened for this PR: https://github.com/php/php-src/pull/947

Asking anyone on the list, would it be possible to make an opcode out
of "namespace Foo\Bar" and letting it set a flag in the runtime system
when run? Then make the flag accessible with a constant like
__NAMESPACE_RUNTIME__ or whatever.

Ooooh, there's an interesting case with "goto" and namespace
visibility here:
https://github.com/php/php-src/pull/947#issuecomment-419821198

That would mean every zval has to carry in which namespace it was
defined inside. I wonder how that would affect the memory footprint of
PHP.

> If we had something like that, then perhaps there could be a
> "delegatable" visibility, which was the equivalent for "protected", but
> when delegating rather than inheriting, e.g.
>
> class Foo {
>  private int $a = 1;
>  delegatable int $b = 2;
> }
>
> class Bar {
>  private delegate Foo $foo;
>  public function __construct(Foo $foo) {
>  $this->foo = $foo;
>  echo $this->a; // Error: can't access private property of a
> different class
>  echo $this->b; // allowed: access is to a "delegatable"
> property, in a "delegated" context
>  }
> }

The Foo class has to decide who to give access to, otherwise it's the
same as public access.

Olle

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

Re: [PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

[Mike Schinkel]

> On Aug 26, 2021, at 9:47 AM, Olle Härstedt  wrote:
> 
> Don't know if this already exists, but maybe we could consider
> brainstorming or gather alternatives for different types of
> encapsulation when using composition? Currently, encapsulation like
> private and protected is only possible when using inheritance - when
> using composition, that is, class A is using (aggregating) class B,
> your only alternative is public, so full visibility (or
> getters/setters, which also is full visibility, since you can't limit
> who's using those methods).

When you say "composition" I think of traits, but it does not appear that is 
what you mean?

I have often wanted to be able to create a trait-private property so that I 
could write a `trait` and be confident that the classes that use it don't start 
using its internal properties and tie my hands in terms of being able to 
upgrade the trait to better internal approaches as I evolve the trait.

Would trait-private address any part of what you need?  Or would other 
trait-specific visibility address what you need? 

And if not, what about traits makes them not-applicable here?  Maybe we could 
also address that?

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

Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Nikita Popov]

On Thu, Aug 26, 2021 at 8:34 PM Ben Ramsey  wrote:

> Nikita Popov wrote on 8/26/21 09:57:
> > Right. I at least do not plan to address this issue. If you take a
> > protected property and publicly re-export it, then any compatibility
> issues
> > are on you.
>
> This does not appear to affect only cases where one is re-exporting a
> protected property as public.
>
> Exception protected properties without type hints:
>
> * PHP <= 8.0 - https://3v4l.org/GWmrk
> * PHP 8.1 - https://3v4l.org/GWmrk/rfc
>
>
> Exception protected properties with type hints:
>
> * PHP <= 8.0 - https://3v4l.org/UX1Pa
> * PHP 8.1 - https://3v4l.org/UX1Pa/rfc
>

These are not really meaningful examples, because you could simply not
redeclare the property at all and assign it in the constructor instead (or
preferably, let the parent constructor assign it). That's the normal way to
extend exceptions. What made the original case interesting is that the
property redeclaration isn't immediately redundant there, because it
changes visibility.

Regards,
Nikita

Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwardscompatbility

[Björn Larsson via internals]

Den 2021-08-26 kl. 20:34, skrev Ben Ramsey:

Nikita Popov wrote on 8/26/21 09:57:

Right. I at least do not plan to address this issue. If you take a
protected property and publicly re-export it, then any compatibility issues
are on you.


This does not appear to affect only cases where one is re-exporting a
protected property as public.

Exception protected properties without type hints:

* PHP <= 8.0 - https://3v4l.org/GWmrk
* PHP 8.1 - https://3v4l.org/GWmrk/rfc


Exception protected properties with type hints:

* PHP <= 8.0 - https://3v4l.org/UX1Pa
* PHP 8.1 - https://3v4l.org/UX1Pa/rfc

Cheers,
Ben


So it looks like we have a bug here since the same code behaves
differently between 8.0 and 8.1.

I don't think it's obvoius that by adding a type hint we get
different behaviour for the "same" code in 8.0 vs 8.1.

The reason I brought this up is that in an Open source library
it's discussed how to solve this. Loading different versions of
the libray feels clunky.

r//Björn L

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

Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Ben Ramsey]

Nikita Popov wrote on 8/26/21 09:57:
> Right. I at least do not plan to address this issue. If you take a
> protected property and publicly re-export it, then any compatibility issues
> are on you.

This does not appear to affect only cases where one is re-exporting a
protected property as public.

Exception protected properties without type hints:

* PHP <= 8.0 - https://3v4l.org/GWmrk
* PHP 8.1 - https://3v4l.org/GWmrk/rfc


Exception protected properties with type hints:

* PHP <= 8.0 - https://3v4l.org/UX1Pa
* PHP 8.1 - https://3v4l.org/UX1Pa/rfc

Cheers,
Ben



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

[Rowan Tommins]

On 26/08/2021 14:47, Olle Härstedt wrote:

Don't know if this already exists, but maybe we could consider
brainstorming or gather alternatives for different types of
encapsulation when using composition?



Although not quite equivalent to your suggestions, these threads on 
making delegation to an encapsulated object might be interesting to you:


*  https://externals.io/message/103353
* https://github.com/php/php-src/pull/5168


If we had something like that, then perhaps there could be a 
"delegatable" visibility, which was the equivalent for "protected", but 
when delegating rather than inheriting, e.g.


class Foo {
    private int $a = 1;
    delegatable int $b = 2;
}

class Bar {
    private delegate Foo $foo;
    public function __construct(Foo $foo) {
    $this->foo = $foo;
    echo $this->a; // Error: can't access private property of a 
different class
    echo $this->b; // allowed: access is to a "delegatable" 
property, in a "delegated" context

    }
}


--
Rowan Tommins
[IMSoP]

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

[PHP-DEV] PHP 7.4.23 Released!

[Derick Rethans]

The PHP development team announces the immediate availability of PHP
7.4.23. This is a security and bug fix release.

All PHP 7.4 users are encouraged to upgrade to this version.

For source downloads of PHP 7.4.23 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site. The list of
changes is recorded in the ChangeLog.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.


php-7.4.23.tar.gz
SHA256 hash: 2aaa481678ad4d2992e7bcf161e0e98c7268f4979f7ca8b3d97dd6de19c205d6
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmElH70ACgkQkQ3rRvU+
oxJnBg/+P3XdZWZG8o8qdDUoPVigfTJreTStS69WN8l7Z4Ln/Dt7yGdkwIOGatGM
O2UQn+tgyIBlHbLmOPHXe4V7ZcGJN3VD/tiY1rWf1XvQdeNVN0YliV8E2Wgd1OP9
PhY9ClmmvfspI2Ykopr7TmlsTl3DZ6iQ/tg1JH4/X6lDSLQs3NLtYBXFUMNKkH3S
gDroExwQsl26ONW5KpMZ1R21Y+MmFRC6ajrB+ipsyj3LnHk3oWpMY1LvdBnYi4e9
7Y19hWwixIguCR3jGkfeD3T3Bl/1LYD6GPvYnQhzvuGbcx9lj800jsPTihRYrPs3
iou+EOfFxdNbI4J5ZVU89lJLzhHlaVf+06m7geA+1c4IGUwS+LQ6EY9wU80tEKNM
IRJvVhUEbQ6uvQbZu5T+IBM6lhI08uWhtkOebkFJH1JKj4aBzCwQmn7COYzo0j61
2ENPbVV/dMH86LRFTKkVaGm6MxRYRpREhFioIzLOCZejkr/9PeRP7RvDcqLs18Fu
UPOttjqcVZ45n2RkZOlmvHxJn8gJ5fZ4RxDlnTWO4lAAoS8HHhPVEeS92NE9cUPD
VefijP5x44czso+61ehOEO1rb2ZW7CChIISX9YfiMMnEZj7uTzXiKwUHO3s15Eth
weTPs7nxZ5rwbdq05aFX72LFapHpykOv+8bUrKISynnKwFgDJTQ=
=tCur
-END PGP SIGNATURE-

php-7.4.23.tar.bz2
SHA256 hash: d1e094fe6e4f832e0a64be9c69464ba5d593fb216f914efa8bbb084e0a7a5727
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmElH8gACgkQkQ3rRvU+
oxIwnRAA14HHZJQ0xheq4OaIqGbS9q0p++ALJFhdrmcq4TX46RdaCQsW4nDmlYcf
zFwSEL5RUbV3Cq1DpHU78iuqjB3SnJuAvF97Cng1dSkrbP8EtSAkUl0QCFpZIwSt
My0ltM+sspKHepPCe1poAigG1Ksd4W+rgDOb9PJ7elKqfgc8kgyivfsA7I6cVk/f
JMU8nVwvEQnj1WE/N9XPQF2JWuEZcAadO5DqnvtZJlFwol36AZFozEb7cs9VoiXh
I3v28ZmIUWlk7iDMi7lItgM94SC/9IPwLQ5txYkSTMAMC2XK2qCn/ape2zK0IOqV
ZGm/Ixx6wJgPms4s+0veRFEZNMP++EI6LKNRGrIC4KlZTtcM9tPzOjkk3sagQrbq
LYl0VkVvJ3LDW81exGgR/SrvxHc0RwTAAF4MCQeGKn/ynG8OXnxtKG/sgoiPr3V2
te4dqkBVv1qd48oNSPGhGp3UcD0NxiNdfGNnIQqyMyyFqBH7Oy3aN1pG7lOGAMuX
NRldSLYwGNxYkx2Ux8A29r9MZjE22KnmC0pDZ9pg32NN6Gxf7KCDqT0PyUeRXDAj
iKLHB+Xw7+5uyyFHf3rbbem777Xv+4SgXdF+9xSb+VTKiC1UmMxQjmADlCy/1aVG
QA1S4otNnXqcld7YGP36Z36tFomacmhm8ge+QOPn5MCiE027Qek=
=8FPG
-END PGP SIGNATURE-

php-7.4.23.tar.xz
SHA256 hash: cea52313fcffe56343bcd3c66dbb23cd5507dc559cc2e3547cf8f5452e88a05d
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmElH8gACgkQkQ3rRvU+
oxLFRw//SpgcQgkfWpS1ysnWbM5Bm8vmHsCQ1y5ZdfUnAqF9LfJlwCh2Uml2A0Rv
djf4fjJ+dh4MlCUUD1TD0cLuumG/N+W/iAnAnujvv/bLoEE2dQPj+KFgcTOqRzT1
AGebvvUSBb69P/aoLUUlNqNToFp8RIc/Hy1n1/SU0TZmLUK3a035hLqGjnBaj0pQ
PbjEPQSBpB/HD1Qo86BZtvRA4sVvf/KiBdggtNEjMbsWPXMLMo2n0+15WZdOnmeR
SDF8FOziGFshDTmDaNmXwt/seHcsjulCHZedADweI66N/vV4k+KaAdkTn5VOXDtU
Md15gSTby7CWyD/Ott4z9I7DQvHv3M1vlYkKZwFI7o4T5Ekvwvadu58OBZRkdIUv
tOkmiPgtXz89OuXCgX3UWzLxuAioHlDjmOoKgTBug6kU/Vrj1COve+oX+5Emxac1
UzdQQoynDVEImkcLjkFICdXaNKS7ifZtpT3/WMVS5Uvs4OKXJyw377Hw9MuCEKp1
elFddNvidKcBtZ4Dp01SZY+EkVZz15YLVU8uN2mXrYYlIkWQc3coNMDIdT1tWAlb
dVIIXeMItOV/vgcotj1weBk9yQs+lzEGhXMq7PzyaygP47+To3uM6TPUbSRbw0Vw
3/5wfXjCEBs0ojmILOqqUn/LcMurGBijHChPm0f/QD1WuEwnacc=
=iMqO
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Nikita Popov]

On Thu, Aug 26, 2021 at 4:43 PM Dan Ackroyd  wrote:

> On Thu, 26 Aug 2021 at 12:42, Björn Larsson via internals
>  wrote:
> >
> > Den 2021-08-10 kl. 11:55, skrev Philip Hofstetter:
> > > The following valid <= PHP 8.0 code that intends to make the $line
> property
> > > public  is a fatal error in 8.1
> 
> > >
> > > For method return types, we have #[ReturnTypeWillChange], but for
> property
> > > types 🤷‍♀️
>
> > Hi,
> >
> > Has this been adressed / solved in some way and does it needs
> > to be fixed?
>
> My understanding is that the two scenarios are not the same and that
> there isn't much enthusiasm for 'fixing' it.
>
> For return types, the #[ReturnTypeWillChange] annotation is a
> temporary work-around, and one that would be used by a lot of people.
> It would only be used by a library until that library drops support
> for older versions of PHP.
>
> For the exception case, the way that (for legacy reasons) PHP supports
> having a public property in a child class that "overwrites" (mostly)
> the protected property in the parent class, is a pretty hinkey thing
> to do, and so this is likely to only affect a small number of people.
> It's not obvious to me how long a bridging annotation would need to
> hang around for, and it's really not obvious what the exact details of
> how it would work would be.
>
> I'd suggest using a getter method, which would work on all relevant
> versions.
>

Right. I at least do not plan to address this issue. If you take a
protected property and publicly re-export it, then any compatibility issues
are on you.

If you need to keep doing this for API stability reasons, then the way to
do it would be a conditional class declaration. Or to keep the scope
smaller, you can conditionally declare a trait with just the property  and
then use it inside a larger class.

Regards,
Nikita

Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Ben Ramsey]

Dan Ackroyd wrote on 8/26/21 09:43:
> On Thu, 26 Aug 2021 at 12:42, Björn Larsson via internals
>  wrote:
>>
>> Den 2021-08-10 kl. 11:55, skrev Philip Hofstetter:
>>> The following valid <= PHP 8.0 code that intends to make the $line property
>>> public  is a fatal error in 8.1
> 
>>>
>>> For method return types, we have #[ReturnTypeWillChange], but for property
>>> types 🤷‍♀️
> 
>> Hi,
>>
>> Has this been adressed / solved in some way and does it needs
>> to be fixed?
> 
> My understanding is that the two scenarios are not the same and that
> there isn't much enthusiasm for 'fixing' it.
> 
> For return types, the #[ReturnTypeWillChange] annotation is a
> temporary work-around, and one that would be used by a lot of people.
> It would only be used by a library until that library drops support
> for older versions of PHP.
> 
> For the exception case, the way that (for legacy reasons) PHP supports
> having a public property in a child class that "overwrites" (mostly)
> the protected property in the parent class, is a pretty hinkey thing
> to do, and so this is likely to only affect a small number of people.
> It's not obvious to me how long a bridging annotation would need to
> hang around for, and it's really not obvious what the exact details of
> how it would work would be.
> 
> I'd suggest using a getter method, which would work on all relevant versions.
> 
> cheers
> Dan
> Ack
> 

It's interesting to note that `$line` and `$file` both behave this way
in PHP 8.1, but `$code` and `$message` do not.

class Foo extends Exception
{
protected $code = 100;
protected $message = 'Hello';
protected $line = 45;
protected $file = '/path/to/file.php';
}

Cheers,
Ben



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Dan Ackroyd]

On Thu, 26 Aug 2021 at 12:42, Björn Larsson via internals
 wrote:
>
> Den 2021-08-10 kl. 11:55, skrev Philip Hofstetter:
> > The following valid <= PHP 8.0 code that intends to make the $line property
> > public  is a fatal error in 8.1

> >
> > For method return types, we have #[ReturnTypeWillChange], but for property
> > types 🤷‍♀️

> Hi,
>
> Has this been adressed / solved in some way and does it needs
> to be fixed?

My understanding is that the two scenarios are not the same and that
there isn't much enthusiasm for 'fixing' it.

For return types, the #[ReturnTypeWillChange] annotation is a
temporary work-around, and one that would be used by a lot of people.
It would only be used by a library until that library drops support
for older versions of PHP.

For the exception case, the way that (for legacy reasons) PHP supports
having a public property in a child class that "overwrites" (mostly)
the protected property in the parent class, is a pretty hinkey thing
to do, and so this is likely to only affect a small number of people.
It's not obvious to me how long a bridging annotation would need to
hang around for, and it's really not obvious what the exact details of
how it would work would be.

I'd suggest using a getter method, which would work on all relevant versions.

cheers
Dan
Ack

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

[PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Ben Ramsey]

Philip Hofstetter wrote on 8/10/21 04:55:
> Hello
> 
> The following valid <= PHP 8.0 code that intends to make the $line property
> public  is a fatal error in 8.1
> 
> class FooException extends Exception {
> public $line;
> }
> 
> However, the fixed code for 8.1:
> 
> class FooException extends Exception {
> public int $line;
> }
> 
> Is a fatal error in <= 8.0
> 
> Is there a way to create a class that makes the $line property public
> that’s compatible with all versions of PHP without requiring conditional
> declaration of the class?
> 
> For method return types, we have #[ReturnTypeWillChange], but for property
> types 🤷‍♀️


This sounds like a bug. I don't see this reported yet in the bug
tracker. Please open an issue at https://bugs.php.net

Cheers,
Ben



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: Alternatives for encapsulation when using composition instead of inheritance

[Olle Härstedt]

2021-08-26 16:20 GMT+02:00, Christoph M. Becker :
> On 26.08.2021 at 15:47, Olle Härstedt wrote:
>
>> * Friend classes, like in C++: Class B is annotated to be a friend of
>> A, so class A can see the content of class B but no other class can.
>
>  has been declined.
>
>> * Namespace private: Class A and B are defined in the same namespace,
>> so they can see each other's properties that are defined as "internal"
>
>  appears to be inactive.
>
> --
> Christoph M. Becker
>

Thanks! I'll check the belonging discussions on externals.io

Olle

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

Re: [PHP-DEV] Unwrap reference after foreach

[Nikita Popov]

On Sat, Aug 14, 2021 at 6:00 PM Claude Pache  wrote:

>
> Le 13 août 2021 à 15:28, Nikita Popov  a écrit :
>
> Hi internals,
>
> I'd like to address a common footgun when using foreach by reference:
> https://wiki.php.net/rfc/foreach_unwrap_ref
>
> This addresses the issue described in the big red box at
> https://www.php.net/manual/en/control-structures.foreach.php. While this
> is
> "not a bug" (as our bug tracker can regularly attest), it's rather
> unexpected, and we could easily avoid it...
>
> Regards,
> Nikita
>
>
> A case that should be mentioned in the RFC is destructuring:
>
> ```php
> foreach ($foo as [ $x, &$y ]) { /*  */ }
> ```
> https://3v4l.org/A5Vi7
>
> I assume that the reference in `$y` would be unwrapped after the loop?
>

I clarified to the RFC to say that
a) unwrapping also occurs if the loop is left using break, continue, goto
etc.
b) unwrapping occurs for array destructuring targets under the same
limitation of "simple variables only". So yes, $y would be unwrapped in
your example.

Regards,
Nikita

[PHP-DEV] Re: Alternatives for encapsulation when using composition instead of inheritance

[Christoph M. Becker]

On 26.08.2021 at 15:47, Olle Härstedt wrote:

> * Friend classes, like in C++: Class B is annotated to be a friend of
> A, so class A can see the content of class B but no other class can.

 has been declined.

> * Namespace private: Class A and B are defined in the same namespace,
> so they can see each other's properties that are defined as "internal"

 appears to be inactive.

--
Christoph M. Becker

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

[PHP-DEV] Alternatives for encapsulation when using composition instead of inheritance

[Olle Härstedt]

Hi list!

Don't know if this already exists, but maybe we could consider
brainstorming or gather alternatives for different types of
encapsulation when using composition? Currently, encapsulation like
private and protected is only possible when using inheritance - when
using composition, that is, class A is using (aggregating) class B,
your only alternative is public, so full visibility (or
getters/setters, which also is full visibility, since you can't limit
who's using those methods).

There are four alternatives at least:

* Friend classes, like in C++: Class B is annotated to be a friend of
A, so class A can see the content of class B but no other class can.
* Package private, like in Java: Class A and B are defined in the same
package, so they can see each other's fields that are defined as
"internal"
* Namespace private: Class A and B are defined in the same namespace,
so they can see each other's properties that are defined as "internal"
* Attribute for namespace private: Like above, but not possible right
now since it requires that namespace is added to the PHP runtime

Functionality like this should not be handled by static analysis,
because library authors need to be able to trust it. Psalm supports
already @internal and @psalm-internal, but of course not everyone is
using Psalm/Phpstan/other analyzer.

The problem with package private is that PHP does not have packages.

The problem with namespace private is that it cannot handle namespace
siblings. Another problem is that it can be "hacked" by client code if
the client code decides to use another vendor's namespace (a weird
thing to do, though).

The run-time hit should not be bigger, since we're already checking
each object property for private. Correct me if I'm wrong.

The risk/benefit/effort should be considered for all alternatives. I'd
argue that something is better than nothing, so far as it does not
block future work. :) Maybe adding namespaces to runtime could be a
first step?

Olle

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

[PHP-DEV] PHP 7.3.30 Released!

[Christoph M. Becker]

The PHP development team announces the immediate availability of PHP
7.3.30.  This is a security release.

All PHP 7.3 users are encouraged to upgrade to this version.

For source downloads of PHP 7.3.30 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: 
Downloads:
Windows downloads:
Changelog:

Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.30.tar.bz2
SHA256 hash:
ccc532e660761df9b5509b9b913d2dc049b0a9954108fe212aeeb8bc2556b502
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmEkxKQMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2uboP/3roXAlnCEn32OxNNGG4+WrQtcJjRNRrIV/efzbH
WdqaEhwUN1aSnV1B3GMXjMp6gM6WejuJSG5NzNCknYRtg85hDH+hmyEbUILiaUHV
J+HV2894meQJDlIr5lnUl8S8X7x8+sD9dSoOnuVsFRz59Dfy5wn4svV+oNUCAdub
XwGUm6haG+lyj6yszABNlaT9huMtAYK2PU+ORtU8GcOY5ildLaSkYmLMbI5BzLWe
cgbWz1Z3lEnC4sXZoi/f7nYOP8kdczfW1uktrTugc7u+4zjUTs4DAKGSaLolKWPS
+MAS6Rd28WGlIRvpKFl4NuS21FH0MF0rlRMmeF4GqEBI0Ub00JhvWTbcP2WM9mrh
xoXnscpQXnP4LVDlfSU0nBilLtN24oJTJglPkgvqablHI9mb23n0+vBt1FUFXgFa
32aZkrD2Whjud0VQOBMb2a/19Zf3n2J3jB7GMZrpi5rLD10F1g9NX9RK0OMvlRv4
Q/NktOeUUO07KFUajH1enrj+kyJ3xjHEdaxmE7Qxx96ASrAxlNFq4FwqhS9P6jYC
MVWnlpBz2SUpwTKyh3MsU6EwN2aWGjN8W2IXA/APt/12U/nZKe4hStFImCjivgSM
XRvp//Y4XwWUMmIXBhZ/E3h4wn3uIJLioZCa9cdYc/dK4QNXsojmVgbxHD5pbrWe
VE/t
=r3KB
-END PGP SIGNATURE-


php-7.3.30.tar.gz
SHA256 hash:
3810a9b631eb7f236ecf02b9a78bab8d957b6cfdb1646a29e3b34e01d36c0510
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmEkxKQMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2W3kP/A/vZE0KWvSPEF5j/MZMMaICy1Kr9D5ZUHulV4lu
FzJ4h3jundZ2rUvF/rHwu0Ww/zyzZnL7XrxWJM7CqG69lFLWLIjPhCcowx3RDLPS
g+0NT11j0BBOpQlCWhBhGSqBWrPBcGU8TAfNmAQzwIcOHErLWmrxb/oZrbWjtzwB
1teKuXUeuTRJ58L5ijCxEKGMkwljiTg7A25V3VC3jGBGnCspaJxp1dKrwAoNr3LA
jpS4b0Cob5PKiisVtEvgTGG9jadNdy55x95thkofLpzXss50p/HZX89DMVCiBXsd
xXVR9rAQAPGQTzbQB9zI+L+2oVR8olrnVrsXqe0OU+ZBvOAWycO1E9XdwQ0JM+1f
fwiMSO7QgH2ByesLOVTM988nBSRqmRgNMDIF4nJcXEHPDsPd6FXHr7r/t0qio/jH
zofbiTNwEyLjyivRPZuF56bJ4d2RmXGM3q7eZ15AjwTpPdHOL1czDjiBibd/90Rj
v9xOUiS7WzmWR+jCk++si8Wa7f6HhqBQ3jE73Cs5lVnz3Qap70mUAd23LhLyiKow
GK1No3sBBL6B4975nANmVCzUrO8NxXVkXbi4pMUCzl3EVBUiVDhxiFAAce0JQoD/
0pVGwn2nInwChLqHcDh/0WUi0xtFy1b7tUWjDrtTxVltF+4PXlCJ6mrfu7vATas9
VNdX
=1R3L
-END PGP SIGNATURE-


php-7.3.30.tar.xz
SHA256 hash:
0ebfd656df0f3b1ea37ff2887f8f2d1a71cd160fb0292547c0ee0a99e58ffd1b
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAmEkxKQMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2NpUQAIz+HE6allfMtMxMkmMdKS8RbidxCKpaA3HXLIVH
T8SEl8qOPDSFlrSyXEBMx7uUSge0ezC38y3mKFvb1STSfUb5q4UqCrvJ76MEybfl
MCvbHR53n6D5jir2nryF3MZWwZWAr/Pg6e18P/+7PgUVqWtlXDOWPPo8zRhKb9Gy
OnfwnVe4Ad2TIlobwo56VjHeM3N0fdOGhd1rlCm6rBNMUcjsVOI7FOqHzXR3T1O1
y0MtSkIsG9IefiawTrpoSUo7CrkUkUFnJcjp4ix9q6zPkKyIiJh8BdW5iBxfnjFj
6TnTM/U1wknU07VO7/zBZK3rbvgnI95lOLcdgzwVj29cLkknT2dAAzo9oMr97eig
55mL2f3oyL8foNPKGF2wcLtCPTvd7xBQMUfPc02k2wyCUJYc/JnKk/UIQzr3D9S/
aQ1ZJPzNcDdiosVW71gBxy1cmubeLNqQI8LSPFQv4ORlC2hfWhnqyu66cWwgU9N/
PGWY+4N9HBiE+Xq7zqV2uexbQUwdF/Tn9UdNM5raDTsX1c6MZUSC/GljPRZsoJUE
hR/MqAuuMt4XIFNasEYryVmaaqmiDjU5agcZOeji7GwbYBZS28JzFmaw/2jLNId4
jDaiUKssh64pINgzqvt8Tp3MN08W54afV16rqR3jTKXaBhaOPNpGUpVS8bBczMWb
ERZJ
=ykrU
-END PGP SIGNATURE-

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

[PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Björn Larsson via internals]

Den 2021-08-10 kl. 11:55, skrev Philip Hofstetter:

Hello

The following valid <= PHP 8.0 code that intends to make the $line property
public  is a fatal error in 8.1

class FooException extends Exception {
 public $line;
}

However, the fixed code for 8.1:

class FooException extends Exception {
 public int $line;
}

Is a fatal error in <= 8.0

Is there a way to create a class that makes the $line property public
that’s compatible with all versions of PHP without requiring conditional
declaration of the class?

For method return types, we have #[ReturnTypeWillChange], but for property
types 🤷‍♀️

Philip


Hi,

Has this been adressed / solved in some way and does it needs
to be fixed?

I mean we are approaching RC1.

r//Björn L

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Mike Schinkel]

> On Aug 26, 2021, at 4:04 AM, Reindl Harald (privat)  wrote:
> Am 26.08.21 um 09:24 schrieb Mike Schinkel:
>> https://3v4l.org/HAkhjW#v8.0.9
>> Total execution time for 5000 iterations for BadActor = 0.351906 milliseconds
>> Total execution time for 5000 iterations for GoodActor = 0.758886 
>> milliseconds
>> Total time difference for 5000 iterations = 0.406981 milliseconds
>> Total time difference for 1 iteration = 1/12,286 millisecond
> 
> that's 46% dude

146% of effectively zero is still effectively zero.

-Mike

[PHP-DEV] Re: PHP 8.0.10 Released!

[Gabriel Caruso]

On Thu, 26 Aug 2021 at 13:04, Gabriel Caruso 
wrote:

> The PHP development team announces the immediate availability of PHP
> 8.0.X. This is a security fix release.
>

PHP 8.0.10, ops.


>
> All PHP 8.0 users are encouraged to upgrade to this version.
>
> For source downloads of PHP 8.0.10 please visit our downloads page.
> Windows binaries can be found on the PHP for Windows site.
> The list of changes is recorded in the ChangeLog.
>
> Release Announcement: 
> Downloads:
> Windows downloads:
> Changelog:
> Release Manifest:<
> https://gist.github.com/carusogabriel/8f0196195b1c4d8e2b20fa264b94f8dd>
>
> Many thanks to all the contributors and supporters!
>
> Gabriel Caruso & Sara Golemon
>
> php-8.0.10.tar.gz
> SHA256 hash: 4612dca9afe8148801648839175ab588097ace66658c6859e9f283ecdeaf84b3
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmElFL0WHGNhcnVzb2dh
> YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjwDID/4+gFqU5elF/VSIexyx9Mnz87Ko
> pU+E1PGYRZqDN1zX3OGvQiPnbkI4XGS06I92ZLBE1DsNtju0WlRmCo2ljQEB5tgP
> 6D75Eoc5Cv5I1Wb4M5pEQjPSM1B+ugO6EFrsTluA3+CvWZCWzkfnt7mgLkfEqm3s
> yTWd7N5ZqKmDyXytpFGNb3266/jKnHuvajMQn12P7Ji6QUPdD6gISkAtoTW0MI+P
> wsDcneMx0iP+/+lEtcxs8X6tg6UrIa7peqWF+VyPE05NyjhSHZQ/vGL3Kfq4Gwre
> FnDUAnQoa314MAN6oVMQ2tkCM59r63zliosXy7AOZ0Z4SeRNC2UsQaGpkqcN5bTg
> SkFVce59HWOzAPiZmkCH6G5TPkQ7dDphnPMhlkYBNhrufpv3Avdmn2mXnclZkjn8
> tkH7iy6td3E0rQTc+YL5XSOTYSPLhgJAjMCtMffVYWume3on4fDJC8PQjg9PDXdq
> gGas2FZhDmvrDzAG7t9KA75NBu1q3nzzABlMnEYe0paLkDcCABxji93tMJarokWw
> l8aY72GC98/uDQNyTFNH2pTZFsXQnQXGYviAJ0uS8X/dyRqRvqNRA4q5fICfeQhg
> XDOXPRJh0bgp2PpAJ/3XYtqKZuIaaTyqkKxolrPdOm0ta07YzvnPcDtWx5txUvML
> H9dHIaQn4kr/3qWO2g==
> =/cbD
> -END PGP SIGNATURE-
>
> php-8.0.10.tar.bz2
> SHA256 hash: c94547271410900845b084ec2bcb3466af363eeca92cb24bd611dcbdc26f1587
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmElFL4WHGNhcnVzb2dh
> YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj0HlEADXz3xaF3L9gaNU3CUa4lMG7rnH
> 9tk1ghRTTMdyZhPlA730kSParYFWDxLbXwQ6GB3iRgnoiLAIPccNOQ1TKbgHe3OM
> G9kMKxbScVy+pV6mPbAPFDBezlDAke/H8gw8nLWZpyhJzV41C6/y4EhRN2wCVMLk
> qJJstutjLcO6prQ1t9Oo0IEOLSwRb2R42FKGE3/8lGhjk5IA8Drx+ZOndgmF5GJL
> pzb4ltt93OMQUgaIQsrtYNBmtLN/MlMY/HScWxG94DCDH34bE6LP0C4DR9udH36g
> ykMn9E+Srnv6ZM6jTFoIjVAM8OtPr6zeJrucBMo0bdzIaoxxEykBMyMrMWcl1qwo
> mvP8/55k0PgM3KiXSBAV3/WlyRsPZ4ISs1dfoAm3oSWwQMGJKYN4lJWGmC7qsQm/
> Kfik4LHV0oEzowXKXVZ4qfbnTCJV+Mbd3PKrDH675uoOCCac9z/hUyId24zk9jO7
> Ssj2dwBzE7l5hj/c77Lfo+FxRmcSgHghyUUZopgdRuoWPufj1RcAr5fMaG5g/q7c
> Xst3SPiHQEmj0VdvXfVJQ7c8eGO1RvLOOEIdOUZ4V+bYPwlZkaZL41AjP+Kakffa
> GogDknrzPDDQz90PezgetzAzXaMURNv0BAvN9YmMG9ISKEOwTbsrV1mtNK01HbW3
> xWVzGZpQt1omoF+zIQ==
> =wBw8
> -END PGP SIGNATURE-
>
> php-8.0.10.tar.xz
> SHA256 hash: 66dc4d1bc86d9c1bc255b51b79d337ed1a7a035cf71230daabbf9a4ca35795eb
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmElFL4WHGNhcnVzb2dh
> YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjxd9D/4015cuqS8R4rWy/aa6sSsxLZxo
> b4NIrHgaKIYTo63sTjTjW64oizc6IY3SYMQbJld4n+9CFvsb6S/mR7Zx1fUcb9UB
> pooYXhLIGIx1xNqPx8dCYo4kc3ZnroVuRXjcoADqYYMcakZc+oRk3I3R+iTWl5Tm
> LU0xNzw8N/w7cKXCF2JKYRGQI1LvC+JdSOVDwfQzK9QwjBxwhuH0TjTY5kNNHfbo
> M3OwNfCoEQy0C7i4cfRiozPrhKUtvkIgxA+9PwvK5Aty4lJEiGkEXrGG8CbQGWUU
> cPrDnK2QIMHoQITn1o41AaV0StbIeJYKtRAq8Tn48ZZicy+xEbETsln1OYPUuGA8
> 9LIdoqEH03XbSZXD3YYZATxCltyUyyJ+CRogMus/Uc5JUHrru0AH5xbD3RMEgtPw
> nInFSQb/dOONRD2K49LulwoataRipJg1tgAKBkc/qSMaBMWiZ6aa8Ylo5UvRcPz3
> eOEw0M38y4nsSmeRwkrtswvyaeiZ5bZGUjG4bXLZgAzH+ApF+ubDltCVTPibriN9
> 7bc/zIVV6SfR711HwHFy6KpqJigt276UYeEE/bP3DduKuhWEeGQyYYt9BUnCOuOt
> LfZ4D7xlmFjCHaRpWMrrHl3s3AmQM29ojSPtfaXGVfFaYgLJ+UZqNom6bafgy0ef
> v5k43vxvsoiu6PUM/A==
> =UClK
> -END PGP SIGNATURE-
>
>
>
>

[PHP-DEV] PHP 8.0.10 Released!

[Gabriel Caruso]

The PHP development team announces the immediate availability of PHP
8.0.X. This is a security fix release.

All PHP 8.0 users are encouraged to upgrade to this version.

For source downloads of PHP 8.0.10 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Release Manifest:<
https://gist.github.com/carusogabriel/8f0196195b1c4d8e2b20fa264b94f8dd>

Many thanks to all the contributors and supporters!

Gabriel Caruso & Sara Golemon

php-8.0.10.tar.gz
SHA256 hash: 4612dca9afe8148801648839175ab588097ace66658c6859e9f283ecdeaf84b3
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmElFL0WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjwDID/4+gFqU5elF/VSIexyx9Mnz87Ko
pU+E1PGYRZqDN1zX3OGvQiPnbkI4XGS06I92ZLBE1DsNtju0WlRmCo2ljQEB5tgP
6D75Eoc5Cv5I1Wb4M5pEQjPSM1B+ugO6EFrsTluA3+CvWZCWzkfnt7mgLkfEqm3s
yTWd7N5ZqKmDyXytpFGNb3266/jKnHuvajMQn12P7Ji6QUPdD6gISkAtoTW0MI+P
wsDcneMx0iP+/+lEtcxs8X6tg6UrIa7peqWF+VyPE05NyjhSHZQ/vGL3Kfq4Gwre
FnDUAnQoa314MAN6oVMQ2tkCM59r63zliosXy7AOZ0Z4SeRNC2UsQaGpkqcN5bTg
SkFVce59HWOzAPiZmkCH6G5TPkQ7dDphnPMhlkYBNhrufpv3Avdmn2mXnclZkjn8
tkH7iy6td3E0rQTc+YL5XSOTYSPLhgJAjMCtMffVYWume3on4fDJC8PQjg9PDXdq
gGas2FZhDmvrDzAG7t9KA75NBu1q3nzzABlMnEYe0paLkDcCABxji93tMJarokWw
l8aY72GC98/uDQNyTFNH2pTZFsXQnQXGYviAJ0uS8X/dyRqRvqNRA4q5fICfeQhg
XDOXPRJh0bgp2PpAJ/3XYtqKZuIaaTyqkKxolrPdOm0ta07YzvnPcDtWx5txUvML
H9dHIaQn4kr/3qWO2g==
=/cbD
-END PGP SIGNATURE-

php-8.0.10.tar.bz2
SHA256 hash: c94547271410900845b084ec2bcb3466af363eeca92cb24bd611dcbdc26f1587
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmElFL4WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj0HlEADXz3xaF3L9gaNU3CUa4lMG7rnH
9tk1ghRTTMdyZhPlA730kSParYFWDxLbXwQ6GB3iRgnoiLAIPccNOQ1TKbgHe3OM
G9kMKxbScVy+pV6mPbAPFDBezlDAke/H8gw8nLWZpyhJzV41C6/y4EhRN2wCVMLk
qJJstutjLcO6prQ1t9Oo0IEOLSwRb2R42FKGE3/8lGhjk5IA8Drx+ZOndgmF5GJL
pzb4ltt93OMQUgaIQsrtYNBmtLN/MlMY/HScWxG94DCDH34bE6LP0C4DR9udH36g
ykMn9E+Srnv6ZM6jTFoIjVAM8OtPr6zeJrucBMo0bdzIaoxxEykBMyMrMWcl1qwo
mvP8/55k0PgM3KiXSBAV3/WlyRsPZ4ISs1dfoAm3oSWwQMGJKYN4lJWGmC7qsQm/
Kfik4LHV0oEzowXKXVZ4qfbnTCJV+Mbd3PKrDH675uoOCCac9z/hUyId24zk9jO7
Ssj2dwBzE7l5hj/c77Lfo+FxRmcSgHghyUUZopgdRuoWPufj1RcAr5fMaG5g/q7c
Xst3SPiHQEmj0VdvXfVJQ7c8eGO1RvLOOEIdOUZ4V+bYPwlZkaZL41AjP+Kakffa
GogDknrzPDDQz90PezgetzAzXaMURNv0BAvN9YmMG9ISKEOwTbsrV1mtNK01HbW3
xWVzGZpQt1omoF+zIQ==
=wBw8
-END PGP SIGNATURE-

php-8.0.10.tar.xz
SHA256 hash: 66dc4d1bc86d9c1bc255b51b79d337ed1a7a035cf71230daabbf9a4ca35795eb
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmElFL4WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjxd9D/4015cuqS8R4rWy/aa6sSsxLZxo
b4NIrHgaKIYTo63sTjTjW64oizc6IY3SYMQbJld4n+9CFvsb6S/mR7Zx1fUcb9UB
pooYXhLIGIx1xNqPx8dCYo4kc3ZnroVuRXjcoADqYYMcakZc+oRk3I3R+iTWl5Tm
LU0xNzw8N/w7cKXCF2JKYRGQI1LvC+JdSOVDwfQzK9QwjBxwhuH0TjTY5kNNHfbo
M3OwNfCoEQy0C7i4cfRiozPrhKUtvkIgxA+9PwvK5Aty4lJEiGkEXrGG8CbQGWUU
cPrDnK2QIMHoQITn1o41AaV0StbIeJYKtRAq8Tn48ZZicy+xEbETsln1OYPUuGA8
9LIdoqEH03XbSZXD3YYZATxCltyUyyJ+CRogMus/Uc5JUHrru0AH5xbD3RMEgtPw
nInFSQb/dOONRD2K49LulwoataRipJg1tgAKBkc/qSMaBMWiZ6aa8Ylo5UvRcPz3
eOEw0M38y4nsSmeRwkrtswvyaeiZ5bZGUjG4bXLZgAzH+ApF+ubDltCVTPibriN9
7bc/zIVV6SfR711HwHFy6KpqJigt276UYeEE/bP3DduKuhWEeGQyYYt9BUnCOuOt
LfZ4D7xlmFjCHaRpWMrrHl3s3AmQM29ojSPtfaXGVfFaYgLJ+UZqNom6bafgy0ef
v5k43vxvsoiu6PUM/A==
=UClK
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Nikita Popov]

On Wed, Aug 25, 2021 at 5:28 PM Sara Golemon  wrote:

> On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov  wrote:
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have not been declared in the class (stdClass and
> > __get/__set excluded, of course):
> >
> > https://wiki.php.net/rfc/deprecate_dynamic_properties
> >
>
> > This RFC offers `extends stdClass` as a way to opt-in to the use of
> dynamic properties.
> >
> This makes the assumption that existing uses of dynamic properties are all
> root classes. I don't think that assumption can be made.
>
> > Some people have suggested that we could use a magic marker
> > interface (implements SupportsDynamicProperties),
> > an attribute (#[SupportsDynamicProperties])
> > or a trait (use DynamicProperties;) instead.
> >
> My gut-check says an Attribute works well enough.  This will unlock the
> class (disable deprecation warning) in 8.2+ and be ignored in earlier
> releases (8.0 and 8.1 would need an auto-loaded polyfill userspace
> attribute obviously, but that's a tractable problem).
>
> #[SupportsDynamicProperties]
> class Foo { ... }
>

The crux of the issue is what our end goal is:

1. Require users to explicitly annotate classes that use dynamic
properties, but otherwise keep dynamic properties as a fully supported part
of the core language.
2. Remove support for dynamic properties entirely. The core language only
has declared properties and __get/__set, and nothing else. stdClass is just
a very efficient implementation of __get/__set.

The RFC is currently written under the assumption that the end goal is (2).
To support that, I believe that "extends stdClass" and "use
DynamicProperties" are the only viable approaches. The former, because it
inherits stdClass behavior, the latter because it's literally __get/__set.
An attribute would require retaining the capability to have arbitrary
classes with dynamic properties.

Now, if the actual goal is (1) instead, then I fully agree that using a
#[SupportsDynamicProperties] attribute is the ideal solution. It can be
easily applied anywhere and has no BC concerns. Heck, someone who just
doesn't care could easily slap it on their whole codebase without spending
brain cycles on more appropriate solutions.

I do think that just (1) by itself would already be very worthwhile. If
that's all we can reasonably target, then I'd be fine with the
#[SupportsDynamicProperties] solution. Though if (2) is viable without too
many complications, then I think that would be the better final state to
reach.


> > The Locked classes RFC took an alternative approach to this problem
> space:
> > Rather than deprecating/removing dynamic properties and providing an
> opt-in
> > for specific classes, it instead allowed marking specific classes as
> locked in
> > order to forbid creation of dynamic properties on them.
> >
> > I don't believe that this is the right strategy, because in contemporary
> code,
> > classes being “locked” is the default state, while classes that require
> dynamic
> > properties are a rare exception. Additionally, this requires that class
> owners
> > (which may be 3rd party packages) consistently add the “locked” keyword
> > to be effective.
> >
> I struggle here, because the opt-in approach is the most BC, but I
> actually think you're right.  I think[citation needed] that dynamic props
> are probably rare enough that as long as the escape hatch is clear, we can
> be a little more bold about nudging the ecosystem forward.  I will counter
> however, that the same issue with 3rd party libraries applies to opt-out as
> opt-in.  A third party library that's undermaintained (and uses dynamic
> props) won't be able to be used out of the box once we apply this.  I don't
> think that's enough to scare us off, it just means that the opt-in side of
> that argument cancels out.
>

I think the argument isn't quite symmetric: A 3rd-party library in
maintenance-only mode has essentially no incentive to go out of their way
and add a "locked" keyword/attribute to their classes. Adding some missing
property declarations to keep working on new PHP versions is a different
matter.

Regards,
Nikita

Re: [PHP-DEV] Guidelines for RFC post feature-freeze

[Hossein Baghayi]

Hello,
One question I have (as I always do) regarding nullable intersection types,
(which is a forbidden topic and I know I shouldn't bring it up).

I'd love to know how `Consistency` plays a role in new RFCs.
Are we striving for consistency?
Is it a value here?
Or simply it is a side effect?

We sorta have nullability everywhere, `function/method parameters`, `return
types`, properties. (please let me know if I am wrong; I'd love to know :D)
Until comes an RFC which intentionally and reasonably drops an area for a
later time but in doing so brings in a new feature that is not consistent
with other parts of the software.

Now we don't have the consistency which we used to have. I know it is
supposed to be temporary but it doesn't make it less inconsistent!

Then came a new RFC which is addressing an issue, which from a different
point of view it could be regarded as fixing this inconsistency.
Now, should we discard this issue and let the inconsistency creep into the
system?
What approaches are we employing for tackling these sorts of issues? Do we
even care about that? :/

>From yet a different point of view, for users unaware of this
inconsistency, it could easily waste their precious time. (Maybe seconds :D
; it doesn't make it less precious)

PS: I'm not conveying anything here (:D). I am simply a curious person.
I also know what feature freeze means and I'm all for it. :)

Regards,

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Mike Schinkel]

> On Aug 26, 2021, at 2:27 AM, Reindl Harald (privat)  wrote:
> Am 26.08.21 um 00:59 schrieb Mike Schinkel:
>>> On Aug 25, 2021, at 6:41 PM, Reindl Harald (privat)  
>>> wrote:
>>> Am 26.08.21 um 00:37 schrieb Mike Schinkel:
 That said, I'd be really interested in seeing use-cases where having 
 dynamic properties is essential to an architecture and where it could not 
 be easily refactored.  I cannot envision any, but I am sure that I am just 
 limited by the extent of my vision and so would like to know what those 
 use-cases would be.
>>> 
>>> public function __get(string $subclass)
>>> {
>>>  $include_file = "{$this->basedir}/modules/{$subclass}/api_{$subclass}.php";
>>>  $class_name = "cl_{$subclass}";
>>>  if(!include $include_file)
>>>  {
>>>   $this->misc->trigger_error("API-LOADER FAILED: '{$subclass}'");
>>>   }
>>>  $this->$subclass = new $class_name;
>>>  $this->$subclass->cl_api = $this;
>>>  return $this->$subclass;
>>> }
>> Easily refactored:
>> public function __get(string $subclass)
>> {
>>   if (isset($this->subclasses[$subclass])) {
>> return $this->subclasses[$subclass];
>>   }
>>   $include_file = "{$this->basedir}/modules/{$subclass}/api_{$subclass}.php";
>>   $class_name = "cl_{$subclass}";
>>   if(!include $include_file)
>>   {
>> $this->misc->trigger_error("API-LOADER FAILED: '{$subclass}'");
>>   }
>>   $this->subclasses[$subclass] = new $class_name;
>>   $this->subclasses[$subclass]->cl_api = $this;
>>   return $this->subclasses[$subclass];
>> }
> 
> and now get is called every single time a property or method in the 
> class-tree is called instead only at the first call
> 
> means in the real world probably thousands of times for each website call - 
> congratulations

https://3v4l.org/HAkhjW#v8.0.9

Total execution time for 5000 iterations for BadActor = 0.351906 milliseconds
Total execution time for 5000 iterations for GoodActor = 0.758886 milliseconds
Total time difference for 5000 iterations = 0.406981 milliseconds
Total time difference for 1 iteration = 1/12,286 millisecond

"Premature optimization is the root of all evil" 
— Sir Tony Hoare 

-Mike

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