Re: [PHP-DEV] Re: RFC: Nested Classes

On 29 April 2025 19:50:52 BST, "Tim Düsterhus" wrote: >I'm saying that I cannot add a private class Foo\Bar inside of the class Foo >without checking whether a class Bar inside a namespace Foo already exists, >since both would conflict. Even more problematic: I can't add a class Bar >inside

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/24/25 21:26, Rob Landers wrote: This was very deliberate after much feedback and careful design. People were quite clear (including yourself, if I recall) that they didn't want a new syntax. Since there is no new syntax, there is no way to tell (from the outside) whether A\B\C refers

Re: [PHP-DEV] Re: RFC: Nested Classes

On Thu, Apr 24, 2025, at 17:20, Tim Düsterhus wrote: > Hi > > On 4/24/25 17:09, Rob Landers wrote: > > Thank you for your feedback! I think you would then have the problem that > > was pointed out by Levi the other day; where you would then have ambiguity. > > If you could have both private an

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/20/25 15:43, Rob Landers wrote: As it seems that discussion has mostly died down, I'd like to put this towards a vote starting on May 1, 2025. Unfortunately I did not have the time to follow the discussion after mid-March, so this might or might not have been discussed already. I ju

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/24/25 17:09, Rob Landers wrote: Thank you for your feedback! I think you would then have the problem that was pointed out by Levi the other day; where you would then have ambiguity. If you could have both private and public names in the same namespace, then you would end up not knowin

Re: [PHP-DEV] Re: RFC: Nested Classes

On Thu, Apr 24, 2025, at 16:31, Tim Düsterhus wrote: > Hi > > On 4/20/25 15:43, Rob Landers wrote: > > As it seems that discussion has mostly died down, I'd like to put this > > towards a vote starting on May 1, 2025. > > Unfortunately I did not have the time to follow the discussion after >

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On Sun, Apr 20, 2025 at 9:30 AM Niels Dossche wrote: > > On 05/04/2025 17:51, Niels Dossche wrote: > > Hi internals > > > > I'm opening the discussion for the RFC "array_first() and array_last()". > > https://wiki.php.net/rfc/array_first_last > > > > Kind regards > > Niels > > > > > Hi > > I'll be

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Tue, Apr 22, 2025, at 19:22, Levi Morrison wrote: > On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote: > > > > On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > > > > Hello internals, > > > > I have significantly revamped the RFC (again). Key changes to the RFC: > > > > 1. More (realistic)

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote: > > On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > > Hello internals, > > I have significantly revamped the RFC (again). Key changes to the RFC: > > 1. More (realistic) examples, > 2. Since enums are basically specialized classes, they are a

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On 22/04/2025 18:51, Levi Morrison wrote: > I don't think it blocks this RFC in any way, and could be made > frameless after the vote--I just wanted to bring up that I think > they _should_ be frameless if they get accepted (and update > array_key_first/array_key_last to be frameless too). Hi Ind

[PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On 05/04/2025 17:51, Niels Dossche wrote: > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels > Hi I'll be putting this to vote on Tuesday 22nd if no one has complaints. Kind regards

[PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > Hello internals, > > I have significantly revamped the RFC (again). Key changes to the RFC: > > 1. More (realistic) examples, > 2. Since enums are basically specialized classes, they are allowed to be > nested as well (hat tip to Reddit), > 3.

Re: [PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, 15 Apr 2025 at 20:59, Daniel Scherzer wrote: > > On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer > wrote: >> >> >> Since a lot of the discussion seems to be around static analysis and whether >> there is a real use case for this, I wanted to share another use case I just >> came across:

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer wrote: > > Since a lot of the discussion seems to be around static analysis and > whether there is a real use case for this, I wanted to share another use > case I just came across: in the `thephpleague/commonmark` package, > different renderers are

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Mon, Mar 10, 2025 at 12:05 PM Daniel Scherzer < daniel.e.scher...@gmail.com> wrote: > Hi internals, > > I'd like to start discussion on a new RFC about allowing `never` for > parameter types when declaring a method. > > * RFC: https://wiki.php.net/rfc/never-parameters-v2 > * Implementation: htt

Re: [PHP-DEV] Re: RFC: short and inner classes

On 24 March 2025 09:20:03 GMT, "Alexandru Pătrănescu" wrote: >On Sun, Mar 23, 2025 at 5:20 PM Larry Garfield >wrote: > >> >> So, how would nested classes compare to fileprivate, in terms of ability >> to solve the problem space? As I understand it, the goal is: >> >> 1. Classes that can be i

Re: [PHP-DEV] Re: RFC: short and inner classes

On Sun, Mar 23, 2025 at 5:20 PM Larry Garfield wrote: > > So, how would nested classes compare to fileprivate, in terms of ability > to solve the problem space? As I understand it, the goal is: > > 1. Classes that can be instantiated only by the class that uses them. > 2. But can be returned fro

Re: [PHP-DEV] Re: RFC: short and inner classes

On Wed, Mar 12, 2025, at 5:10 AM, Rob Landers wrote: > Hello internals, > > I've made some major updates to the text of the RFC to clarify > behaviors and revisited the implementation (which is still under > development, though I hope to have a draft by the end of this weekend). > Here's a broa

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-14 01:22, schrieb Bob Weinand: […] class constants in uppercase […] enum cases are a notable Exception. They also use PascalCase (both internal enums and the PER-CS coding style as published by PHP-FIG). But that's also a good question for the RFC author: Is defining inner cl

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-13 21:46, schrieb Rob Landers: I will give \\ a try, but it has to be typed quite a bit when referencing inner classes, so keeping it easy to type is a must. I feel like \\ requires a large movement to type, at least on a qwerty non-english keyboard. Maybe people using other keyb

Re: [PHP-DEV] Re: RFC: short and inner classes

On Wed, Mar 12, 2025, at 11:10, Rob Landers wrote: > On Thu, Mar 6, 2025, at 00:11, Rob Landers wrote: >> Hello PHP Internals, >> >> I'd like to introduce my RFC for discussion: >> https://wiki.php.net/rfc/short-and-inner-classes >> >> This RFC defines a short class syntax as well as the ability

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 23:26, Bob Weinand wrote: > Hey Rob, > > On 13.3.2025 21:46:49, Rob Landers wrote: >> On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: >>> Hi >>> >>> Am 2025-03-12 11:10, schrieb Rob Landers: >>> > - Accessing inner classes is done via a new token: ":>" instead of

Re: [PHP-DEV] Re: RFC: short and inner classes

Hey Rob, On 14.3.2025 00:26:03, Rob Landers wrote: My biggest issue with `::` is that it gets weird: class Foo {   public class Bar {}   public const Bar = "";   public static function Bar() {} } echo Foo::Bar; // this is the constant new Foo::Bar(); // this is the class Foo::Bar(); // this is

Re: [PHP-DEV] Re: RFC: short and inner classes

Hey Rob, On 13.3.2025 21:46:49, Rob Landers wrote: On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: Hi Am 2025-03-12 11:10, schrieb Rob Landers: > - Accessing inner classes is done via a new token: ":>" instead of > "::". I don't particularly like that. It is “invented syntax” and I don't

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 21:41, Ilija Tovilo wrote: > Hi Rob > > On Thu, Mar 13, 2025 at 1:57 PM Rob Landers wrote: > > > > > the proposal is > > > currently quite complex. > > > > Most of this is just describing how classes work already and going in-depth > > on where there may be confusion --

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: > Hi > > Am 2025-03-12 11:10, schrieb Rob Landers: > > - Accessing inner classes is done via a new token: ":>" instead of > > "::". > > I don't particularly like that. It is “invented syntax” and I don't > think that inner classes are suffi

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Rob On Thu, Mar 13, 2025 at 1:57 PM Rob Landers wrote: > > > the proposal is > > currently quite complex. > > Most of this is just describing how classes work already and going in-depth > on where there may be confusion -- there are no significant changes to how > classes actually work. The

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 12:41, Ilija Tovilo wrote: > Hi Rob > > On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus wrote: > > > > Am 2025-03-12 11:10, schrieb Rob Landers: > > > - Accessing inner classes is done via a new token: ":>" instead of > > > "::". > > > > I don't particularly like that. It

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Rob On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus wrote: > > Am 2025-03-12 11:10, schrieb Rob Landers: > > - Accessing inner classes is done via a new token: ":>" instead of > > "::". > > I don't particularly like that. It is “invented syntax” and I don't > think that inner classes are suffic

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-12 11:10, schrieb Rob Landers: - Accessing inner classes is done via a new token: ":>" instead of "::". I don't particularly like that. It is “invented syntax” and I don't think that inner classes are sufficiently valuable to dedicate an entire operator to them that could serve

[PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 6, 2025, at 00:11, Rob Landers wrote: > Hello PHP Internals, > > I'd like to introduce my RFC for discussion: > https://wiki.php.net/rfc/short-and-inner-classes > > This RFC defines a short class syntax as well as the ability to nest classes > inside another class. This introduces a

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Tue, Mar 4, 2025, 23:22 Tim Düsterhus wrote: > > > Or identify that the function has the NoDiscard attribute and based on > that > > do not optimize away the variable? > > First things first: It's not a super important optimization to have, the > assignment to a variable is one of the cheaper

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi On 3/4/25 23:08, Alexandru Pătrănescu wrote: Just asking, as my engine knowledge is a bit limited, Wouldn't it be possible that when OPcache would optimize away the unused variable assigned to a function, it could detect that that function have the NoDiscard attribute and also remove the attr

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Tim, On Tue, Mar 4, 2025, 22:16 Tim Düsterhus wrote: > Hi Marc > > Should the `(void)` cast not be accepted, we will only special case the > assignment to `$_` to not be elided, even if OPcache knows that the > function will never return an object. The behavior for other variables > will rema

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Marc On 3/3/25 17:14, Marc B. wrote: In this thread, I only found the information that currently OPcache does not discard such unused assignments. It would be good to know if such optimization could be considered to not end up in a situation that such optimization would be useful but can't be

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi,Am 03.03.2025 15:30 schrieb Volker Dusch :On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote:Volker and I would like to start discussion on our RFC to allow "Markingreturn values as important (#[\NoDiscard])".Please find the following resources for your reference:- RFC: http

[PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > Volker and I would like to start discussion on our RFC to allow "Marking > return values as important (#[\NoDiscard])". > > Please find the following resources for your reference: > > - RFC: https://wiki.php.net/rfc/marking_return_value_as_im

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Am 2025-02-14 10:10, schrieb Jakob Givoni: I think all the native attributes so far, with the exception of #[\AllowDynamicProperties], only affect the program at compile-time, or by emitting errors. They don't affect the program otherwise by changing behavior, throwing exceptions etc. (As lon

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Fri, Feb 14, 2025 at 1:10 PM Aleksander Machniak wrote: > On 14.02.2025 12:57, Derick Rethans wrote: > > None of the current attributes (ReturnTypeWillChange, > > AllowDynamicProperties, SensitiveParameter, Override, and Deprecated) > > change the behaviour of how a program runs. They only add

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On 14.02.2025 12:57, Derick Rethans wrote: None of the current attributes (ReturnTypeWillChange, AllowDynamicProperties, SensitiveParameter, Override, and Deprecated) change the behaviour of how a program runs. They only add warnings. with the exception of AllowDynamicProperties to be an actual '

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Thu, 13 Feb 2025, Tim Düsterhus wrote: > Am 2025-02-13 09:16, schrieb Jakob Givoni: > > > Attributes were added as a structured replacement for docblock props > > and I don't like it when they affect how a program actually runs (as > > long as you're not using reflection). > > Excluding the

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Thu, 13 Feb 2025, Larry Garfield wrote: > On Thu, Feb 13, 2025, at 8:16 AM, Tim Düsterhus wrote: > > Hi > > > > Am 2025-02-12 22:31, schrieb Larry Garfield: > >> I'm still undecided on the RFC overall, but one thing that is > >> problematic is the phrasing of the messages. Currently, the mess

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Wed, 12 Feb 2025, Volker Dusch wrote: > On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > > > Volker and I would like to start discussion on our RFC to allow "Marking > > return values as important (#[\NoDiscard])". > > > > Please find the following resources for your reference: > > > >

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Thu, Feb 13, 2025 at 3:17 PM Tim Düsterhus wrote: > Hi > > Am 2025-02-13 09:16, schrieb Jakob Givoni: > > Attributes were added as a structured replacement for docblock props > > and I > > don't like it when they affect how a program actually runs (as long as > > you're not using reflection).

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Thu, Feb 13, 2025, at 8:16 AM, Tim Düsterhus wrote: > Hi > > Am 2025-02-12 22:31, schrieb Larry Garfield: >> I'm still undecided on the RFC overall, but one thing that is >> problematic is the phrasing of the messages. Currently, the messages >> in the attribute are fragments of an English se

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Am 2025-02-13 09:49, schrieb Eugene Sidelnyk: I'm just wondering how the new attribute that defines behavior (not just additional metadata) will fit into the rest of the system. See my reply to Jakob: There are already several attributes that define behavior. Do you think it's reasonab

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Am 2025-02-13 09:16, schrieb Jakob Givoni: Attributes were added as a structured replacement for docblock props and I don't like it when they affect how a program actually runs (as long as you're not using reflection). Excluding the `#[\Attribute]` attribute, PHP currently has 5 native at

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hi Am 2025-02-12 22:31, schrieb Larry Garfield: I'm still undecided on the RFC overall, but one thing that is problematic is the phrasing of the messages. Currently, the messages in the attribute are fragments of an English sentence, seemingly designed to fit grammatically with a sentence fra

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

Hello, everyone I'm just wondering how the new attribute that defines behavior (not just additional metadata) will fit into the rest of the system. Right now, return type hints are not implemented just as an attribute, but as "native" type declaration. I mean, what we have right now: function f

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

My thoughts overall on this: 0. I'm not against introducing the attribute, only how it's used/enforced etc. (And, incidentally, what it actually MEANS, see if you can spot that from the rest of my comments) 1. Static analysers and IDEs: I agree with everyone who's said that whether or not the

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On 2025-02-13 00:52, Volker Dusch wrote: b) Naming of the attribute Nobody mentioned this on the list, but before opening a vote we'd like to heard if the attribute name makes sense to you. On this, it could be spelled #[\MustUse], rather than phrase it as a negative.

Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Wed, Feb 12, 2025, at 5:52 AM, Volker Dusch wrote: > On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: >> Volker and I would like to start discussion on our RFC to allow "Marking >> return values as important (#[\NoDiscard])". >> >> Please find the following resources for your reference: >

[PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])

On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > Volker and I would like to start discussion on our RFC to allow "Marking > return values as important (#[\NoDiscard])". > > Please find the following resources for your reference: > > - RFC: https://wiki.php.net/rfc/marking_return_value_as_im

[PHP-DEV] Re: RFC: First Class Callables in constant expressions

On Wed, Jan 22, 2025 at 3:35 PM Tim Düsterhus wrote: > - RFC: https://wiki.php.net/rfc/fcc_in_const_expr > - Implementation: https://github.com/php/php-src/pull/17213 With the two weeks discussion time elapsing later today and given the feedback we received, we plan to open the vote tomorrow pe

[PHP-DEV] Re: [RFC] [Discussion] Error backtraces v2

On Thu, Dec 5, 2024 at 3:57 PM Eric Norris wrote: > > Hello yet again internals, > > I'd like to formally propose a continuation of the original error > backtraces RFC (https://wiki.php.net/rfc/error_backtraces): > > https://wiki.php.net/rfc/error_backtraces_v2 > > We recently had a production inc

[PHP-DEV] Re: [RFC] [Discussion] Error backtraces v2

On Mon, Dec 16, 2024 at 11:17 AM Eric Norris wrote: > > Hello, > > We're nearing the two-week mark, so I'm curious if anyone has any > other feedback or points of discussion for this RFC. > > In particular, I'm interested to know if anyone has thoughts on a > suggestion I had in one of the reply t

[PHP-DEV] Re: [RFC] [Discussion] Error backtraces v2

Hello, We're nearing the two-week mark, so I'm curious if anyone has any other feedback or points of discussion for this RFC. In particular, I'm interested to know if anyone has thoughts on a suggestion I had in one of the reply threads - that we could consider something to the effect of allowing

[PHP-DEV] Re: [RFC] [Discussion] Attributes on compile-time constants

On Sat, Nov 30, 2024 at 9:00 AM Daniel Scherzer wrote: > Hi again, > > Based on feedback to my last thread[1] that an RFC would be needed to > allow attributes on constants, I have just filed > https://wiki.php.net/rfc/attributes-on-constants and added it to the > "Under Discussion" section on th

[PHP-DEV] Re: [RFC] PHP.net analytics

On Fri, Nov 1, 2024, at 4:41 PM, Larry Garfield wrote: > In a similar vein to approving the use of software, Roman Pronskiy > asked for my help putting together an RFC on collecting analytics for > PHP.net. > > https://wiki.php.net/rfc/phpnet-analytics > > Of particular note: > > * This is self-h

Re: [PHP-DEV] Re: [RFC] [Discussion] Persistent CurlShareHandle objects

On Thu, Oct 24, 2024, at 13:01, Christoph M. Becker wrote: > On 23.10.2024 at 21:42, Rob Landers wrote: > > > On Wed, Oct 23, 2024, at 21:20, Eric Norris wrote: > > > >> Were you also suggesting that I shouldn't ask a question about the > >> implementation regarding using EG(persistent_list) vs.

Re: [PHP-DEV] Re: [RFC] [Discussion] Persistent CurlShareHandle objects

On 23.10.2024 at 21:42, Rob Landers wrote: > On Wed, Oct 23, 2024, at 21:20, Eric Norris wrote: > >> Were you also suggesting that I shouldn't ask a question about the >> implementation regarding using EG(persistent_list) vs. a module >> global? I'm torn; I agree that it is an implementation detai

Re: [PHP-DEV] Re: [RFC] [Discussion] Persistent CurlShareHandle objects

On Wed, Oct 23, 2024, at 19:10, Eric Norris wrote: > Hello again, > > It has been two weeks, and unless there are any further comments I > plan on converting the above question into a voteable sub-question and > opening the RFC for votes tomorrow, Thursday October 24th. > > Thanks! > Hello,

Re: [PHP-DEV] Re: [RFC] [Discussion] Persistent CurlShareHandle objects

On Wed, Oct 23, 2024, at 21:20, Eric Norris wrote: > Apologies Rob, I don't seem to be receiving individual emails from the > mailing list, so I'll have to respond to my own email here. I've > changed my subscription to receive all emails so hopefully I'll be > able to respond directly to future

[PHP-DEV] Re: [RFC] [Discussion] Persistent CurlShareHandle objects

Apologies Rob, I don't seem to be receiving individual emails from the mailing list, so I'll have to respond to my own email here. I've changed my subscription to receive all emails so hopefully I'll be able to respond directly to future emails. > It might be a good idea to get a “strong opinion”

[PHP-DEV] Re: [RFC] [Discussion] Persistent CurlShareHandle objects

Hello again, It has been two weeks, and unless there are any further comments I plan on converting the above question into a voteable sub-question and opening the RFC for votes tomorrow, Thursday October 24th. Thanks!

[PHP-DEV] Re: [RFC] Decoding HTML and the Ambiguous Ampersand

All, I have updated the RFC document by adding a section on the proposed HtmlContext enum, with some extra contexts than were originally discussed (but which were added to the implementation). As I’ve been a bit distracted this has taken a bit of a backseat but I am still interested in keeping

Re: [PHP-DEV] Re: [RFC] Default expression

On 1 September 2024 17:45:57 BST, Rob Landers wrote: >Is manually copying the default also not type-safe? Is php a type-safe >language? I think a lot of the arguments I saw suggested that people don't >review libraries and their implementations when upgrading or installing them. >This is jus

Re: [PHP-DEV] Re: [RFC] Default expression

On Sun, Sep 1, 2024, at 14:39, Rowan Tommins [IMSoP] wrote: > On 29/08/2024 22:52, Bilge wrote: > > On 24/08/2024 17:49, Bilge wrote: > >> > >> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I > >> think some of you might enjoy this one. Hit me with any feedback. > >> > > Now t

Re: [PHP-DEV] Re: [RFC] Default expression

On 29/08/2024 22:52, Bilge wrote: On 24/08/2024 17:49, Bilge wrote: New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think some of you might enjoy this one. Hit me with any feedback. Now the dust has settled, I've updated the RFC to version 1.1. The premise of the RFC is

Re: [PHP-DEV] Re: [RFC] Default expression

On Thu, 29 Aug 2024, at 22:52, Bilge wrote: >> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I >> think some of you might enjoy this one. Hit me with any feedback. >> > Now the dust has settled, I've updated the RFC to version 1.1. The > premise of the RFC is unchanged, but t

Re: [PHP-DEV] Re: [RFC] Default expression

One thought re-reading the RFC. abstract class Theme { public function bar(); } class CuteTheme extends Theme { public function foo(); } class Config { public function __construct(Theme $theme = new CuteTheme()) {} } $a = new Config(default->foo()); In the proposed (updated) RFC would this be p

[PHP-DEV] Re: [RFC] Default expression

Hi gang, On 24/08/2024 17:49, Bilge wrote: New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think some of you might enjoy this one. Hit me with any feedback. Now the dust has settled, I've updated the RFC to version 1.1. The premise of the RFC is unchanged, but the propo

Re: [PHP-DEV] Re: [RFC] [vote] Support object type in BCMath

On Thursday, May 16 2024 at 17:22, Saki Takamachi wrote: > Hi all, > > > 2024/05/01 17:55、Saki Takamachi のメール: > > > > Hi all! > > > > Voting for RFC: Support object type in BCMath has started. Voting ends > on 2024-05-16 00:00 GMT. > > https://wiki.php.net/rfc/support_object_type_in_bcmath > > >

Re: [PHP-DEV] Re: [RFC] Decoding HTML and the Ambiguous Ampersand

On 20/08/2024 00:45, Dennis Snell wrote: > >> On Jul 9, 2024, at 4:55 PM, Dennis Snell wrote: >> >> Greetings all, >> >> The `html_entity_decode( … ENT_HTML5 … )` function has a number of issues >> that I’d like to correct. >> >>  - It’s missing 720 of HTML5’s specified named character reference

[PHP-DEV] Re: [RFC] Decoding HTML and the Ambiguous Ampersand

> On Jul 9, 2024, at 4:55 PM, Dennis Snell wrote: > > Greetings all, > > The `html_entity_decode( … ENT_HTML5 … )` function has a number of issues > that I’d like to correct. > > - It’s missing 720 of HTML5’s specified named character references. > - 106 of these are named character referen

[PHP-DEV] Re: [RFC][VOTE] Lazy Objects

> > Hi all, > > We have just opened the vote for the Lazy Objects RFC: > https://wiki.php.net/rfc/lazy-objects > > The vote will close on August 11th à 00:00. > > Please check the discussion thread if you didn't follow it already: > https://externals.io/message/123503 > > Cheers, > Nicolas and Ar

[PHP-DEV] Re: [RFC] [Vote] Add bcdivmod to BCMath

Hi all, > > Hi all! > > RFC: Add bcdivmod to BCMath has started voting. > https://wiki.php.net/rfc/add_bcdivmod_to_bcmath > > Voting ends on 2024-08-01 00:00:00 UTC. > > Regards, > > Saki My report was delayed due to poor health. The vote passed with 21 votes in favor and 0 votes against. h

[PHP-DEV] Re: [RFC] [Vote] Fix up BCMath Number Class / Change GMP bool cast behavior

Hi all, > Hi all, > > RFC: Fix up BCMath Number Class / Change GMP bool cast behavior has started > voting. > https://wiki.php.net/rfc/fix_up_bcmath_number_class > > Voting ends on 2024-07-30 00:00:00 UTC. > > Regards, > > Saki Both RFCs were passed with 18 votes in favor and 0 votes agains

[PHP-DEV] Re: [RFC] Static class

On 24/06/2024 00:10, Bilge wrote: Hi Internals! I am pleased to present my first RFC: Static class . Gentle reminder that voting is scheduled to start Monday, barring any unexpected developments over this weekend. The RFC is unchanged since including

Re: [PHP-DEV] Re: [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

Hi Gina, > Thank you, I am happy will all the provided amendments now! > > Best regards, > > Gina P. Banyard Thank you! All the issues mentioned have now been resolved and the vote is expected to go ahead as scheduled. Regards, Saki

Re: [PHP-DEV] Re: [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

On Wednesday, 10 July 2024 at 07:35, Saki Takamachi wrote: > Added one more change to the RFC. > > Currently, there is no other expression for comparison in PHP called "comp”. > The expression "cmp" is mainly used for functions, and the expression > "compare" is used for class methods. > > e.

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Hi I'm specifically replying to Nicolas, but this email is directed to the general public, so please feel free to reply even if you are not called Nicolas :-) On 6/24/24 17:06, Nicolas Grekas wrote: 2/ About the "since" parameter, we're going to standardize around a package+version string,

[PHP-DEV] Re: [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

Hi all, > Hi internals, > > Created a follow-up RFC for the BCMath\Number class. This RFC also contains > proposed changes to GMP's bool cast. I have proposed similar changes to > BCMath, so for procedural efficiency I have combined them into the same RFC. > > Note that although they are combi

[PHP-DEV] Re: [RFC] Static class

On 07/07/2024 21:08, Bilge wrote: On 24/06/2024 00:10, Bilge wrote: Hi Internals! I am excited to announce the final implementation for Static Class is ready for review at and includes a brief summary of the key semantics of the feature. Furthermor

[PHP-DEV] Re: [RFC] Static class

On 24/06/2024 00:10, Bilge wrote: Hi Internals! I am excited to announce the final implementation for Static Class is ready for review at and includes a brief summary of the key semantics of the feature. Furthermore, the 1.3 (presumed) final version

Re: [PHP-DEV] Re: [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

> This seems positive to me. Rounding being explicit makes more sense. Thanks! Saki

Re: [PHP-DEV] Re: [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

On Tue, Jul 2, 2024 at 4:06 AM Saki Takamachi wrote: > Hi all, > > > Hi internals, > > > > Created a follow-up RFC for the BCMath\Number class. This RFC also > contains proposed changes to GMP's bool cast. I have proposed similar > changes to BCMath, so for procedural efficiency I have combined t

[PHP-DEV] Re: [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

Hi all, > Hi internals, > > Created a follow-up RFC for the BCMath\Number class. This RFC also contains > proposed changes to GMP's bool cast. I have proposed similar changes to > BCMath, so for procedural efficiency I have combined them into the same RFC. > > Note that although they are combi

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Hi On 6/27/24 13:10, Nicolas Grekas wrote: That's sad news, because I keep explaining why engine-triggered runtime notices are a terrible idea, yet you're planning to add more of them. The consistency argument Tim wrote in another email isn't sound to me: consistency with a bad idea doesn't make

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Le mar. 25 juin 2024 à 22:01, Benjamin Außenhofer a écrit : > > > On Mon, Jun 24, 2024 at 5:07 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> >> >> Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a >> écrit : >> >>> >>> >>> On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer >

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

On Mon, Jun 24, 2024 at 5:07 PM Nicolas Grekas wrote: > > > Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a > écrit : > >> >> >> On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer >> wrote: >> >>> The vote for the RFC #[\Deprecated] attribute is now open: >>> >>> https://wiki.php.net/rfc/de

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Hi On 6/24/24 17:06, Nicolas Grekas wrote: Since the vote passed, we're discussing how we might use the attribute in Symfony. 2 things on the topic: 1/ We're wondering about using it at the class level despite the missing Attribute::TARGET_CLASS. ReflectionAttribute does allow reading attribute

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

On Mon, Jun 24, 2024, 7:35 PM Stephen Reay wrote: > > Sent from my iPhone > > On 24 Jun 2024, at 23:43, Matthew Weier O'Phinney < > mweierophin...@gmail.com> wrote: > >  > > > On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> >> >> Le mer. 5 juin 2024

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Sent from my iPhoneOn 24 Jun 2024, at 23:43, Matthew Weier O'Phinney wrote:On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas wrote:Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a écrit :On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer

[PHP-DEV] Re: [RFC] [Vote] New ext-dom features in PHP 8.4

On 10/06/2024 20:10, Niels Dossche wrote: > Hi internals > > I'm opening the vote of my RFC "New ext-dom features in PHP 8.4". > RFC link: https://wiki.php.net/rfc/dom_additions_84 > Voting runs until 24th of June 21:00 GMT+2. > > Kind regards > Niels Hi internals The RFC was accepted with 25 y

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas < nicolas.grekas+...@gmail.com> wrote: > > > Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a > écrit : > >> >> >> On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer >> wrote: >> >>> The vote for the RFC #[\Deprecated] attribute is now open: >>>

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a écrit : > > > On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer > wrote: > >> The vote for the RFC #[\Deprecated] attribute is now open: >> >> https://wiki.php.net/rfc/deprecated_attribute >> >> Voting will close on Wednesday 5th June, 08:00 G

Re: [PHP-DEV] Re: RFC karma request

Hi Bilage On Thu, Jun 20, 2024 at 7:55 PM Bilge wrote: > > > > Re: Static class, I would like to propose an RFC for this feature. My > > wiki account is: bilge. > > > > Cheers, > > Bilge > > > If there is some reason why I should not be able to do this, please let > it be known. Sorry for the de

[PHP-DEV] Re: RFC karma request

On 18/06/2024 20:27, Bilge wrote: Hi Internals, Re: Static class, I would like to propose an RFC for this feature. My wiki account is: bilge. Cheers, Bilge If there is some reason why I should not be able to do this, please let it be known. Cheers, Bilge

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

Hi On 6/5/24 10:16, Benjamin Außenhofer wrote: Tim will finalize the implementation PR now and work on its merge in the upcoming days. During review Ilija pointed out that adding the internal ZEND_ACC_DEPRECATED flag was skipped for abstract methods and interface methods, questioning the de

  1   2   3   4   5   6   7   8   9   10   >