On Wed, May 29, 2024, at 7:51 PM, Tim Düsterhus wrote:
> Hi
>
> On 5/29/24 21:15, Larry Garfield wrote:
>> * We've brought back the abbreviated form, as public-read, something else
>> set is the most common use case.
>
> The most common use case is that 'get' and 'set' are symmetric.
OK, fair,
Hi
On 5/29/24 21:53, Andreas Hennings wrote:
Is there a reason why we cannot just make it "public private string
$x" instead of "public private(set) string $x"?
We would define that the second visibility specifier is for write.
The current proposal with "public private(set)" is less ambiguous,
On Wed, May 29, 2024, at 7:53 PM, Andreas Hennings wrote:
> Hello Larry,
> just a quick thought.
> Is there a reason why we cannot just make it "public private string
> $x" instead of "public private(set) string $x"?
> We would define that the second visibility specifier is for write.
>
> The
Hello Larry,
just a quick thought.
Is there a reason why we cannot just make it "public private string
$x" instead of "public private(set) string $x"?
We would define that the second visibility specifier is for write.
The current proposal with "public private(set)" is less ambiguous, and
it is
Hi
On 5/29/24 21:15, Larry Garfield wrote:
* We've brought back the abbreviated form, as public-read, something else set
is the most common use case.
The most common use case is that 'get' and 'set' are symmetric. Any
divergence from that should stand out and I think that the hamming
On Tue, 28 May 2024, Tim Düsterhus wrote:
> On 5/28/24 16:26, Derick Rethans wrote:
>
> > I have just checked this for Xdebug, and you're definitely right
> > with that. With the removal of the ZEND_EXIT opcode, it can not now
> > detect a scope/function exit now.
>
> Can you clarify why
Hi
On 5/28/24 16:26, Derick Rethans wrote:
I have just checked this for Xdebug, and you're definitely right with
that. With the removal of the ZEND_EXIT opcode, it can not now detect a
scope/function exit now.
Can you clarify why ZEND_EXIT is special for Xdebug when compared to any
other
On Tue, 28 May 2024, Gina P. Banyard wrote:
> On Tuesday, 28 May 2024 at 15:26, Derick Rethans wrote:
>
> > On Mon, 27 May 2024, Ilija Tovilo wrote:
> >
> > > On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe
> > > wrote:
> > >
> > > > On Wednesday, 8 May 2024 at 14:40, Gina
On Tuesday, 28 May 2024 at 15:26, Derick Rethans wrote:
> On Mon, 27 May 2024, Ilija Tovilo wrote:
>
> > On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe
> > wrote:
> >
> > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard
> > > intern...@gpb.moe wrote:
> > >
> > > > I
On Mon, 27 May 2024, Ilija Tovilo wrote:
> On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard
> wrote:
> >
> > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard
> > wrote:
> >
> > > I would like to formally propose my idea for exit() as a function
> > > brought up to the list on 2024-02-24
On Tue, May 28, 2024 at 2:10 PM Gina P. Banyard wrote:
>
> On Monday, 27 May 2024 at 02:31, Ilija Tovilo wrote:
>
> > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard intern...@gpb.moe
> > > wrote:
> > >
> > > > I would like to formally propose my idea for exit() as a function
> > > >
On Monday, 27 May 2024 at 02:31, Ilija Tovilo wrote:
> Hi Gina
>
> On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe wrote:
>
> > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard intern...@gpb.moe wrote:
> >
> > > I would like to formally propose my idea for exit() as a
On Monday, 27 May 2024 at 19:10, Claude Pache wrote:
> Hi Gina,
>
> It is ok, for `exit` to be wired to a function. However, the paren-less
> `exit` syntax is absolutely reasonable and should be kept in the long term
> (more on this below). It is true that your proposal doesn’t remove the
>
On Tuesday, 28 May 2024 at 07:53, Daikaras wrote:
>
> I feel like the reasoning in this RFC is misguided. `exit` behavior is
> not consistent with functions because it is not a function. But it is
> consistent with constructs like `echo`. Or am I wrong? I'm all for
> stricter typing but not at a
On 2024.04.07 17:20, Joshua Rüsweg wrote:
Hi
I have created an RFC to add the function array_find which returns the
first element for which a predicate callback returns true. This is a
function which I missed often. Furthermore this type of function is
implemented with other programming
On 2024.05.08 16:40, Gina P. Banyard wrote:
Hello Internals,
I would like to formally propose my idea for exit() as a function brought up to
the list on 2024-02-24 [1] with the following RFC:
https://wiki.php.net/rfc/exit-as-function
There have been some slight tweaks to the implementation,
On 22/05/2024 19:47, Niels Dossche wrote:
> Okay, that seems reasonable to me and I can do that.
> I'll make them return static and do "new static()" like I proposed with the
> new static method.
>
> For XMLWriter, I suppose we also want the static counterparts:
> * `XMLWriter::toMemory()` for
Hi Gina
On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard wrote:
>
> On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard wrote:
>
> >
> > I would like to formally propose my idea for exit() as a function brought
> > up to the list on 2024-02-24 [1] with the following RFC:
> >
On Tuesday, 14 May 2024 at 17:24, Juliette Reinders Folmer
wrote:
> On 11-5-2024 16:43, Gina P. Banyard wrote:
>
>> On Thursday, 9 May 2024 at 15:17, Jorg Sowa
>> [](mailto:jorg.s...@gmail.com) wrote:
>>
I don't think there are any other "functions" like this.
>>> What about list(),
Hi
On 5/25/24 01:19, Valentin Udaltsov wrote:
Have you considered renaming `$callback` parameter to `$predicate`? I
always considered "callback" to be a very generic word. Predicate, on the
contrary, implies accepting a value and returning a bool.
For an entirely new API I would agree. But
On Sun, Apr 7, 2024, at 10:20 AM, Joshua Rüsweg wrote:
> Hi
> I have created an RFC to add the function array_find which returns the
> first element for which a predicate callback returns true. This is a
> function which I missed often. Furthermore this type of function is
> implemented with
On 21/05/2024 21:58, Claude Pache wrote:
>
>
>> Le 21 mai 2024 à 21:00, Matthew Weier O'Phinney a
>> écrit :
>>
>> (But again, I prefer that all those methods work on instances, as it was
>> the case before PHP 8. They shouldn’t have been switched to
>> static-but-broken-for-subclasses
On Wednesday, 22 May 2024 at 08:22, 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 GMT.
I have voted in favour of the RFC, I don't have any strong
On Wed, 22 May 2024 at 11:01, Pierre wrote:
> Le 22/05/2024 à 09:33, Nicolas Grekas a écrit :
>
> Hi Benjamin,
>
> 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 GMT.
>>
>
> I
On Wed, May 22, 2024 at 9:33 AM Nicolas Grekas
wrote:
> Hi Benjamin,
>
> 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 GMT.
>>
>
> I voted "no" because I think this is better
Le 22/05/2024 à 09:33, Nicolas Grekas a écrit :
Hi Benjamin,
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 GMT.
I voted "no" because I think this is better addressed in
Hey Benjamin,
I voted against it:
* I very much like having reflection methods that work on internal symbols
relying on `#[\Deprecated]`. I can rely on these in my static analysis
tooling, test suites, decorators, dependency injection tools, etc.
* I am still disagree with abusing global runtime
Hi Benjamin,
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 GMT.
>
I voted "no" because I think this is better addressed in userland, as this
gives more flexibility.
I would better
> Le 21 mai 2024 à 21:00, Matthew Weier O'Phinney a
> écrit :
>> (But again, I prefer that all those methods work on instances, as it was the
>> case before PHP 8. They shouldn’t have been switched to
>> static-but-broken-for-subclasses without discussion.)
>
> Fixing the existing ones
On Tue, May 21, 2024 at 12:58 PM Claude Pache
wrote:
>
>
> > Le 18 mai 2024 à 01:13, Niels Dossche a écrit
> :
> >
> > On 22/04/2024 20:41, Niels Dossche wrote:
> >> Hi internals
> >>
> >> I'm opening the discussion for my RFC "Add openStream() to
> XML{Reader,Writer}".
> >> RFC link:
> Le 18 mai 2024 à 01:13, Niels Dossche a écrit :
>
> On 22/04/2024 20:41, Niels Dossche wrote:
>> Hi internals
>>
>> I'm opening the discussion for my RFC "Add openStream() to
>> XML{Reader,Writer}".
>> RFC link: https://wiki.php.net/rfc/xmlreader_writer_streams
>>
>> Kind regards
>>
Hi
On 5/9/24 15:10, Andreas Hennings wrote:
The syntax is well suited for the most common case, which is regular
wither methods for one or more known properties.
I don't like the array syntax as a default. It has inferior DX for
regular withers, and possible performance impact from the
On Thu, May 16, 2024, at 22:31, Patrik Václavek wrote:
> This feature aims to simplify and standardize the process of verifying that a
> variable is an instance of a specific class, enhancing code readability and
> reducing boilerplate code.
>
> Currently, in PHP, to ensure that a variable is
On Thu, May 16, 2024 at 1:32 PM Patrik Václavek wrote:
> Introduction
> *
>
> This RFC proposes a new feature in PHP: type guards for classes (or
> interfaces). This feature aims to simplify and standardize the process of
> verifying that a variable is an instance of a specific
On Thu, May 16, 2024, at 3:31 PM, Patrik Václavek wrote:
> Introduction
> *
>
> This RFC proposes a new feature in PHP: type guards for classes (or
> interfaces). This feature aims to simplify and standardize the process
> of verifying that a variable is an instance of a specific
Hi Patrik
On Thu, May 16, 2024 at 10:31 PM Patrik Václavek wrote:
>
> Introduce a new type guard syntax for classes:
>
> ```php
> (Foo) $variable;
> ```
>
> This syntax will internally perform the following operations:
>
> 1. Check if `$variable` is an instance of `Foo`.
> 2. If the check fails,
On Thu, 16 May 2024 at 22:33, Patrik Václavek wrote:
> Introduction
> *
>
> This RFC proposes a new feature in PHP: type guards for classes (or
> interfaces). This feature aims to simplify and standardize the process of
> verifying that a variable is an instance of a specific class,
On 11-5-2024 16:43, Gina P. Banyard wrote:
On Thursday, 9 May 2024 at 15:17, Jorg Sowa wrote:
> I don't think there are any other "functions" like this.
What about list(), isset(), print(), echo(), require(), include(),
unset(), empty()? We use them the same way as functions, but those
are
Hi all,
Regarding some of the points, I have decided to address them as th follow-up
RFC.
Further discussion will take place in a separate thread.
Regards,
Saki
On 11 May 2024 15:43:19 BST, "Gina P. Banyard" wrote:
>print, echo, include(_once) and require(_once) do not mandate their "argument"
>to be passed within parenthethis, so making them functions does not simplify
>the lexer/parser nor removes them as keywords.
It's actually a much stronger
On Thursday, 9 May 2024 at 16:18, Saki Takamachi wrote:
> Hi Gina,
>
> > Hello Internals,
> >
> > I would like to formally propose my idea for exit() as a function brought
> > up to the list on 2024-02-24 [1] with the following RFC:
> > https://wiki.php.net/rfc/exit-as-function
> >
> > There
On Thursday, 9 May 2024 at 15:17, Jorg Sowa wrote:
>> I don't think there are any other "functions" like this.
> What about list(), isset(), print(), echo(), require(), include(), unset(),
> empty()? We use them the same way as functions, but those are not real
> functions.
> Kind regards,
>
On Saturday, 11 May 2024 at 09:05, Juliette Reinders Folmer
wrote:
> On 8-5-2024 15:40, Gina P. Banyard wrote:
>
>> I would like to formally propose my idea for exit() as a function brought up
>> to the list on 2024-02-24 [1] with the following RFC:
>> https://wiki.php.net/rfc/exit-as-function
On 8-5-2024 15:40, Gina P. Banyard wrote:
I would like to formally propose my idea for exit() as a function brought up to
the list on 2024-02-24 [1] with the following RFC:
https://wiki.php.net/rfc/exit-as-function
There have been some slight tweaks to the implementation, namely that the
Hi Tim,
> This is already the case. `exit` throws an internal uncatchable Exception.
> Quoting from the RFC:
Thanks, I had overlooked that. I have no other concerns.
Regards,
Saki
Hi
On 5/9/24 17:18, Saki Takamachi wrote:
Is it nonsense to always stop processing even if an error occurs? Or, how about
creating an uncatchable exception class specifically for exits? Or is this
level of risk negligible?
This is already the case. `exit` throws an internal uncatchable
Hi
On 5/9/24 16:27, Larry Garfield wrote:
I support this. My only question (which applies to current exit() as well), is
what the exit code is when you pass a string as the parameter. That's not
clear from the exit() docs currently, but the RFC made me wonder. (This may be
just a doc fix
Hi
On 5/9/24 16:17, Jorg Sowa wrote:
I don't think there are any other "functions" like this.
What about list(), isset(), print(), echo(), require(), include(), unset(),
empty()? We use them the same way as functions, but those are not real
functions.
All of them require to be followed by
On Thu, May 9, 2024, at 5:12 PM, Valentin Udaltsov wrote:
> Yes, I've done that, see https://externals.io/message/123293.
D'Oh. At almost the exact same time I replied. :-) Thanks.
(Also, please do not top post.)
--Larry Garfield
Yes, I've done that, see https://externals.io/message/123293.
чт, 9 мая 2024 г. в 20:11, Larry Garfield :
> On Thu, May 9, 2024, at 3:26 PM, Valentin Udaltsov wrote:
> > @Lynn, @Alex, thank you for your comments. I have improved the "without
> > constructor arguments' parentheses" part of the
On Thu, May 9, 2024, at 3:26 PM, Valentin Udaltsov wrote:
> @Lynn, @Alex, thank you for your comments. I have improved the "without
> constructor arguments' parentheses" part of the introduction section
> and started the voting.
I believe standard procedure expects you to post a new message to
@Lynn, @Alex, thank you for your comments. I have improved the "without
constructor arguments' parentheses" part of the introduction section and
started the voting.
вт, 23 апр. 2024 г. в 16:55, Alexandru Pătrănescu :
>
> On Tue, Apr 23, 2024 at 3:31 PM Robert Landers
> wrote:
>
>> On Tue, Apr
Hi Gina,
> Hello Internals,
>
> I would like to formally propose my idea for exit() as a function brought up
> to the list on 2024-02-24 [1] with the following RFC:
> https://wiki.php.net/rfc/exit-as-function
>
> There have been some slight tweaks to the implementation, namely that the
>
On Wed, May 8, 2024, at 1:40 PM, Gina P. Banyard wrote:
> Hello Internals,
>
> I would like to formally propose my idea for exit() as a function
> brought up to the list on 2024-02-24 [1] with the following RFC:
> https://wiki.php.net/rfc/exit-as-function
>
> There have been some slight tweaks to
> I don't think there are any other "functions" like this.
What about list(), isset(), print(), echo(), require(), include(), unset(),
empty()? We use them the same way as functions, but those are not real
functions.
Kind regards,
Jorg
On Thu, May 9, 2024, at 1:10 PM, Andreas Hennings wrote:
>> Where all properties are readonly, and if an object those are *also*
>> readonly, and all are assigned in the constructor...
>>
>> Yeah, that ideal case is kinda narrow, and likely will remain so for a long
>> while yet.
>>
>>
On Tue, 7 May 2024, Gina P. Banyard wrote:
> On Tuesday, 7 May 2024 at 15:46, Saki Takamachi wrote:
>
> > On Tue, 7 May 2024, Gina P. Banyard wrote:
> >
> > > - Are the existing BCMath function going to be adapted to handle
> > > the new Number object or not?
> >
> > No, that is not
On Thu, 9 May 2024, Matteo Beccati wrote:
> Il 03/05/2024 11:14, Matteo Beccati ha scritto:
> >
> > I've updated once again the RFC and implemented most of the 3 major
> > dialects (mysql, pgsql, sqlite) in the drivers.
> >
> > https://wiki.php.net/rfc/pdo_driver_specific_parsers
> >
> >
On Thu, 9 May 2024, Flávio Heleno wrote:
> On Thu, May 9, 2024 at 7:51 AM Niels Dossche
> wrote:
>
> > On 08/05/2024 15:40, Gina P. Banyard wrote:
> > > Hello Internals,
> > >
> > > I would like to formally propose my idea for exit() as a function
> > > brought up to the list on 2024-02-24 [1]
On Tue, 13 Jun 2023 at 22:13, Larry Garfield wrote:
>
> On Tue, Jun 13, 2023, at 3:51 PM, Máté Kocsis wrote:
> > Hi Larry,
> >
> > In this case, if the `with` happens first, then the new address object is
> >> cloned needlessly, but that *probably* doesn't hurt anything. But $newAddr
> >> !==
On Thu, May 9, 2024 at 7:51 AM Niels Dossche
wrote:
> On 08/05/2024 15:40, Gina P. Banyard wrote:
> > Hello Internals,
> >
> > I would like to formally propose my idea for exit() as a function
> brought up to the list on 2024-02-24 [1] with the following RFC:
> >
On 08/05/2024 15:40, Gina P. Banyard wrote:
> Hello Internals,
>
> I would like to formally propose my idea for exit() as a function brought up
> to the list on 2024-02-24 [1] with the following RFC:
> https://wiki.php.net/rfc/exit-as-function
>
> There have been some slight tweaks to the
Hi,
Il 03/05/2024 11:14, Matteo Beccati ha scritto:
Hi internals!
I've updated once again the RFC and implemented most of the 3 major
dialects (mysql, pgsql, sqlite) in the drivers.
https://wiki.php.net/rfc/pdo_driver_specific_parsers
https://github.com/php/php-src/pull/14035
I've tried
Hi
On 5/8/24 15:40, Gina P. Banyard wrote:
Let me know what you think.
The fewer not-actually-a-function functions, the better. I don't have
any remarks and I'm in favor.
Best regards
Tim Düsterhus
Hello list,
to revive this old RFC.
One really nice application of never parameters is with intersection types:
interface I {}
interface ReturnI {
public function foo(never $x): I;
}
interface AcceptI {
public function foo(I $x): mixed;
}
function f(ReturnI $arg, I $x): I {
return
Hi
On 5/6/24 20:44, Joshua Rüsweg wrote:
I don't think that any internal functions are realistically passed
there, but rather user-defined ones. I would therefore not make the
function any more complicated than it already is. If the function works
differently with internal functions than with
Hi
On 5/7/24 17:23, Gina P. Banyard wrote:
- What is the behaviour when casting a Number object to bool? Does it always cast to true
like a "standard" object, or does a Number equal to 0 cast to false?
That's a good topic. I didn't include any mention of this in the RFC because
there was
On Tuesday, 7 May 2024 at 15:46, Saki Takamachi wrote:
> Hi Gina,
>
> > I voted in favour, as Number being its own type should improve DX and
> > performance for small numbers as we can just store two 64bit integer, one
> > for the integral and another for the fractional part.
> > However, I
Hi Gina,
> I voted in favour, as Number being its own type should improve DX and
> performance for small numbers as we can just store two 64bit integer, one for
> the integral and another for the fractional part.
> However, I have some remarks and questions.
> Apologies if these were already
On Wednesday, 1 May 2024 at 09:55, Saki Takamachi wrote:
> 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
>
> Regards,
>
> Saki
I voted in favour, as Number being its own
Hi
On 02.05.24 15:27, Larry Garfield wrote:
It's not just that it errors confusingly. It's that the design as is would be
incompatible with any C-based function. A function that works with anything
*except* the standard library seems... problematic.
It's possible that, since these new
Hi internals!
I've updated once again the RFC and implemented most of the 3 major
dialects (mysql, pgsql, sqlite) in the drivers.
https://wiki.php.net/rfc/pdo_driver_specific_parsers
https://github.com/php/php-src/pull/14035
I've tried to keep syntax changes we might not want as separate
On Wed, May 1, 2024, at 9:26 PM, Joshua Rüsweg wrote:
> Hi
>
> On 01.05.24 12:26, Larry Garfield wrote:
>> This looks good to me, with one remaining exception, which isn't specific to
>> this function but should still be discussed: Always passing the value and
>> key to the callback is unsafe,
Hi
On 01.05.24 12:26, Larry Garfield wrote:
This looks good to me, with one remaining exception, which isn't specific to
this function but should still be discussed: Always passing the value and key
to the callback is unsafe, for two reasons.
1. If the callback is an internal function rather
Hi
On 19.04.24 23:29, Tim Düsterhus wrote:> Thinking about this: I believe
that it would make sense to bundle
array_any and array_every (or array_all, see below) within the same RFC
due to the similarity. It can be a separate vote for those two, but
having the option of getting all three
On Tue, Apr 23, 2024, at 7:53 PM, Joshua Rüsweg wrote:
> Hi
>
> On 19.04.24 21:20, Joshua Rüsweg wrote:
>> I definitely see the point where there is an advantage to having two
>> separate methods and can definitely understand that it is easier for
>> developers to understand the control flow
Hi Alex,
> Just one small note from me, for mod operation, related to scale there is a
> mention of "Use the scale of the dividend as is".
> In reality, I think it should be the same as add and sub, "The larger scale
> of the two values is applied".
> In this way, something like this can work
On Tue, Apr 30, 2024 at 7:31 AM Saki Takamachi wrote:
> Hi,
>
> If there is no further discussion, I will start voting tomorrow. (I
> haven't decided on the time yet.)
> https://wiki.php.net/rfc/support_object_type_in_bcmath
>
>
>
Just one small note from me, for mod operation, related to scale
Hi,
If there is no further discussion, I will start voting tomorrow. (I haven't
decided on the time yet.)
https://wiki.php.net/rfc/support_object_type_in_bcmath
Regards,
Saki
On 29/04/2024 20:58, Larry Garfield wrote:
On Mon, Apr 15, 2024, at 4:43 PM, Larry Garfield wrote:
The vote for the Property Hooks RFC is now open:
https://wiki.php.net/rfc/property-hooks
Voting will close on Monday 29 April, afternoonish Chicago time.
The vote has now been closed. The
On Mon, Apr 15, 2024, at 4:43 PM, Larry Garfield wrote:
> The vote for the Property Hooks RFC is now open:
>
> https://wiki.php.net/rfc/property-hooks
>
> Voting will close on Monday 29 April, afternoonish Chicago time.
The vote has now been closed. The final tally is 42 Yes and 2 No, meaning it
On 15/04/2024 17:43, Larry Garfield wrote:
The vote for the Property Hooks RFC is now open:
https://wiki.php.net/rfc/property-hooks
Voting will close on Monday 29 April, afternoonish Chicago time.
I'm somewhat conflicted on this one. On the one hand, I think the
feature will be very
On Fri, Apr 26, 2024 at 6:43 AM Richard Miles wrote:
>
> Howdy everyone,
>
> I’m reaching out in an attempt to start an RFC for the apach2handler module,
> and I'm eager to hear your perspectives. I’ve already created a Draft PR on
> GitHub (https://github.com/php/php-src/pull/14047), and I am
On Fri, Apr 26, 2024 at 11:01 AM Benjamin Außenhofer
wrote:
> After discussing with Mate shortly one reason for adding $since from a PHP
> project POV is that we do show the $since information in the generated
> documentation output.
>
> Integrating with the work in progress to auto generate
Sent from my iPhone
> On 26 Apr 2024, at 22:06, Rowan Tommins [IMSoP] wrote:
>
>
>
>> On 26 April 2024 09:40:57 BST, Mike Schinkel wrote:
>>
>> Given a lack of agreed definition for 'since' it appears you are using
>> narrow assumptions about the meaning of 'since' that led you to view
On 26 April 2024 09:40:57 BST, Mike Schinkel wrote:
>Given a lack of agreed definition for 'since' it appears you are using narrow
>assumptions about the meaning of 'since' that led you to view 'since' as
>useless.
I can't see any ambiguity in the definition: "This function has been
> On Apr 25, 2024, at 5:47 PM, Rowan Tommins [IMSoP]
> wrote:
> I think you missed the context of that sentence - or I'm missing something in
> yours. I meant specifically that the "deprecated since" information is
> useless if there's no published policy on how long something will stay
>
On Tue, Apr 23, 2024 at 7:27 PM Levi Morrison
wrote:
> On Tue, Apr 23, 2024 at 7:30 AM Benjamin Außenhofer
> wrote:
> >
> > Hi internals,
> >
> > My PR for #[\Deprecated] attribute was in hibernation for a long while
> now and after some off-list discussion a few weeks ago I have decided to
>
On 25 April 2024 22:01:35 BST, Mike Schinkel wrote:
>> On Apr 25, 2024, at 11:28 AM, Rowan Tommins [IMSoP]
>> wrote:
>> If the project has no clear deprecation policy, the information is useless
>> anyway.
>
>Not true.
>
>Having standardized notation for deprecation would allow tooling to
> On Apr 25, 2024, at 11:28 AM, Rowan Tommins [IMSoP]
> wrote:
> If the project has no clear deprecation policy, the information is useless
> anyway.
Not true.
Having standardized notation for deprecation would allow tooling to analyze a
codebase and determine if it contains deprecated code
On 25/04/2024 08:40, Stephen Reay wrote:
If you're on X.y and it says it was deprecated in X.w you know you
don't need to worry about it being removed until at least Y.a.
Yeah, that's the reasoning given in the Rust discussion, but I don't
find it convincing.
If the project's deprecation
Sent from my iPhone
> On 25 Apr 2024, at 16:26, Rowan Tommins [IMSoP] wrote:
>
> On 24 April 2024 18:18:28 BST, Jorg Sowa wrote:
>> What about setting this parameter vaguely as the boolean we can pass?
>> ...
>> #[Deprecated(since: $packageVersion > 5.5)]
>> #[Deprecated(since:
On 24 April 2024 18:18:28 BST, Jorg Sowa wrote:
> What about setting this parameter vaguely as the boolean we can pass?
> ...
> #[Deprecated(since: $packageVersion > 5.5)]
> #[Deprecated(since: PHP_VERSION_ID > 80100)]
> #[Deprecated(since: date("Y-m-d") > "2024-01-21")]
Even if these
On Wed, Apr 24, 2024 at 7:18 PM Jorg Sowa wrote:
> I like the proposition and I like the idea of $since parameter, however,
> this option is too ambiguous about what should store. Should it store the
> PHP version, package version, or the date?
>
> What about setting this parameter vaguely as
On 24/04/2024 10:22, Claude Pache wrote:
>
>
>> Le 23 avr. 2024 à 21:23, Niels Dossche a écrit :
>>
>> On 22/04/2024 21:53, Larry Garfield wrote:
>>> On Mon, Apr 22, 2024, at 6:41 PM, Niels Dossche wrote:
Hi internals
I'm opening the discussion for my RFC "Add openStream() to
I like the proposition and I like the idea of $since parameter, however,
this option is too ambiguous about what should store. Should it store the
PHP version, package version, or the date?
What about setting this parameter vaguely as the boolean we can pass?
#[Attribute(Attribute::TARGET_METHOD
On Wed, Apr 24, 2024 at 2:55 PM Lynn wrote:
>
>
> On Tue, Apr 23, 2024 at 3:30 PM Benjamin Außenhofer
> wrote:
>
>> Hi internals,
>>
>> My PR for #[\Deprecated] attribute was in hibernation for a long while
>> now and after some off-list discussion a few weeks ago I have decided to
>> revisit
On Wed, Apr 24, 2024 at 3:57 PM Nicolas Grekas
wrote:
> Hi Benjamin,
>
> My PR for #[\Deprecated] attribute was in hibernation for a long while now
>> and after some off-list discussion a few weeks ago I have decided to
>> revisit it and asked Tim to help me out with the work.
>>
>> Tim has
Hi Benjamin,
My PR for #[\Deprecated] attribute was in hibernation for a long while now
> and after some off-list discussion a few weeks ago I have decided to
> revisit it and asked Tim to help me out with the work.
>
> Tim has cleaned up the PR quite a bit and also worked in additional
>
On Tue, Apr 23, 2024 at 3:30 PM Benjamin Außenhofer
wrote:
> Hi internals,
>
> My PR for #[\Deprecated] attribute was in hibernation for a long while now
> and after some off-list discussion a few weeks ago I have decided to
> revisit it and asked Tim to help me out with the work.
>
> Tim has
1 - 100 of 18822 matches
Mail list logo
