Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hey Dan. I do appriciate to hear your point of view. This thread is now very off-topic. With respect to Marco and other people that wants to discuss guidelines for the RFCs and the role of RMs, I will not answer you anymore. Feel free to reach out to me privately or in a new thread. // Tobias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Fri, 27 Aug 2021 at 19:11, Tobias Nyholm wrote: > Hey Dan. > > I see that you read what I wrote and intrepid it in the worst possible way. This is also passive aggressive phrasing. You're trying to make me feel bad for pointing out how your phrasing is not conducive to a pleasant productive conversation. > I called it an “obvious mistake” because it was clear to me that we missed > something. 'We' didn't miss it. You might have, but multiple people have explained multiple times that it was a deliberate choice to limit the scope of work for one RFC. If you had written "I consider it a mistake" that leaves room for other people to have a different opinion. But you have kept writing things like "Just because it was intentional, does not make it less of a mistake." which is dismissive of other people's point of view. > I think there are over 1000 people with “voting powers”. I assume > you trust a majority of them to have this “deep enough understanding of PHP > core”. Well. Most of the time people will only vote if they feel they understand the subject being discussed, and have enough confidence that voting a particular way is the right choice. That's quite different from trying to make someone _have_ to say yes or no. But there is at least one RFC that, in my opinion, there were a lot of people who voted who did not fully understand the technical details, or the implications for on-going maintenance: https://wiki.php.net/rfc/jit > If you don’t trust the release managers to manage the release, Ben is right, I didn't say that. I was responding to your sentence which was "what to include and not to include in a release.". > then I suggest you should improve the way we select new release managers. 'Volunteering' other people to do work is also a passive aggressive way of phrasing things. You're the person who is apparently unhappy with the current process that has been used for over a decade. If you want it changed, you do the work to change it. > This is the the extended power I would like the RMs (as a group) to have. That is also volunteering other people for more work. IMO the position of RM is already stressful enough, to the extent that I will never volunteer to be one, as it would cause me to have a nervous breakdown. Making it so that they also have to be arbiters of which post feature freeze RFCs are 'valid' or not would be an extra, and stressful, burden for them to carry. Pierre Joye wrote: > > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md Well, as the mailing rules have been linked, I might as well quote this bit: "Do not top post. Place your answer underneath anyone you wish to quote and remove any previous comment that is not relevant to your post." sincerely Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] timelib performance fix
Hi Derick, Please, let me know you decision according https://github.com/derickr/timelib/pull/99 This workaround fix makes ~170 times improvement on "new DateTimeZone()" and as result visible improvement on some real-life apps (e.g Symfony demo gets ~7% according to callgrind). This is a huge difference. The fix was proposed more than a half year ago... It would be great to include it into PHP-8.1 release. Thanks. Dmitry.
Re: [PHP-DEV] [RFC] Deprecate dynamic properties
On Mon, Aug 30, 2021 at 2:14 PM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le Wed, 25 Aug 2021 12:02:49 +0200,
> Nikita Popov a écrit :
> > Hi internals,
> >
> > 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
>
> If I understand correctly the RFC, in these two classes:
>
> class A {
> public $prop;
>
> public function __construct() {
> unset($this->prop);
> }
> }
>
> class B {
> public $prop;
> }
>
> The property $prop is not in the same state in the end? What is the
> difference?
> isset returns FALSE for both, no? And property_exists?
>
In the latter case, the property has value null. In the former case, it is
unset. In both cases, it is declared. Accessing an unset property will
trigger __get/__set. Accessing a null property will not (assuming it is
visible).
Is it something that was the same before the RFC and would be different
> after,
> or is it already two different cases and how?
This RFC does not have any impact on this behavior. This is a "standard"
pattern used for lazy initialization.
Regards,
Nikita
Re: [PHP-DEV] [RFC] Deprecate dynamic properties
Le Wed, 25 Aug 2021 12:02:49 +0200,
Nikita Popov a écrit :
> Hi internals,
>
> 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
If I understand correctly the RFC, in these two classes:
class A {
public $prop;
public function __construct() {
unset($this->prop);
}
}
class B {
public $prop;
}
The property $prop is not in the same state in the end? What is the difference?
isset returns FALSE for both, no? And property_exists?
Is it something that was the same before the RFC and would be different after,
or is it already two different cases and how?
Côme
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
