> On 30 May 2023, at 07:48, Andreas Hennings wrote:
>
> Hello internals,
> I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
> https://externals.io/message/110217#110395
> (we probably had the idea independently, but Benjamin's is the first
> post where I see it menti
Hello list,
this proposal will be useful in combination with "Declaration-aware attributes"
Problem
Currently, ReflectionMethod is not aware of the original class, if the
method is declared in a parent class.
Methods that are called during a discovery algorithm that need to
process a met
I just notice a flaw in my thinking.
On Tue, 30 May 2023 at 02:48, Andreas Hennings wrote:
>
> Note that for methods, we typically need to know the method reflector
> _and_ the class reflector, because the method could be defined in a
> base class.
This is true when doing a discovery using attri
Thanks for the feedback!
On Tue, 30 May 2023 at 03:43, Dusk wrote:
>
> On May 29, 2023, at 17:48, Andreas Hennings wrote:
> > Quite often I found myself writing attribute classes that need to fill
> > some default values or do some validation based on the symbol the
> > attribute is attached to.
On May 29, 2023, at 17:48, Andreas Hennings wrote:
> Quite often I found myself writing attribute classes that need to fill
> some default values or do some validation based on the symbol the
> attribute is attached to.
> E.g. a parameter attribute might require a specific type on that
> parameter
A big TBD would be the new attribute classes we need to mark these parameters.
Perhaps we could use just one attribute class, e.g.
"AttributeDeclaration", and use the parameter type to determine which
part of the declaration is expected.
Also, if an attribute is allowed on different symbol types,
Hello internals,
I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
https://externals.io/message/110217#110395
(we probably had the idea independently, but Benjamin's is the first
post where I see it mentioned in the list)
Quite often I found myself writing attribute class
Hi Claude,
The replacement methods for IntlCalendar::set() (namely
> IntlCalendar::setDate() and IntlCalendar::setDateTime()) must not have a
> return type of `void`, but `true`, like the original method, for the two
> following reasons:
>
> 1. By changing the returned value, you are introducing a
Hi Michał and Larry,
As Tim has already clarified, using literal strings in the left-hand side
of "clone with expressions" won't cause any issues
for IDEs and static analysers to identify the correct property. I got rid
of the shorthand syntax from the proposal because
it is not strictly required
> Le 8 mai 2023 à 23:38, Larry Garfield a écrit :
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
>
Hi
On 5/29/23 08:44, Go Kudo wrote:
I realized I was about to add the deprecation of `lcg_value()` and forgot
to do so, so I added it.
https://wiki.php.net/rfc/deprecations_php_8_3#global_combined_lcg
As usual, my English is of low quality, so I would appreciate it if you
could point out any p
> Le 11 mai 2023 à 18:37, Tim Düsterhus a écrit :
>
> Hi
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
>
>
> RFC: Marking overridden methods (#[\Override])
> https://wiki.php.net/rfc/marking_overriden_methods
>
Hi Tim,
One weakness of t
Hi
On 5/29/23 13:47, Michał Marcin Brzuchalski wrote:
So there would be no option to vote on shorthand properties, right?
Array syntax with all properties as strings in quotes probably means no
support from IDE.
I think this is a really bad move, I'd be against it.
I expect any IDE or SA too
Hi
On 5/23/23 17:47, Sara Golemon wrote:
I think targeting 8.3 is aggressive as we're less than a month from FF
(accounting for discussion and voting period).
I didn't expect the proposal to need much of a discussion, as the
functionality is known from existing programming languages and the
On 29.05.2023 14:12, Aleksander Machniak wrote:
In "Property name expressions" section's first code example I think you
intended to do `clone $self` (not `clone $this`) inside the foreach() loop.
Also, I have a feeling that it would be better to implement `clone
$object with $properties` synta
> Le 27 avr. 2023 à 23:28, Máté Kocsis a écrit :
>
> Hi Internals,
>
> As you have possibly already experienced, overloaded signatures cause
> various smaller and bigger issues, while the concept is not natively
> supported by PHP. That's why I drafted an RFC which intends to phase out
> the m
Hi
On 5/27/23 23:10, Rowan Tommins wrote:
So the argument is that the key estimate for whether to include it in the
engine is how many users will add the attribute, but not run a static analysis
tool. If that number is very low, adding it to the engine has a very low value.
As mentioned in m
Hi
On 5/24/23 01:32, David Gebler wrote:
where you're coming from, however I'd refer back to my earlier comment: any
attributes added in the engine should provide a tangible benefit which
*can't be achieved in userland*.
I think this is a flawed premise: Any sort of analysis that PHP itself
2023年5月30日(火) 0:42 Nikita Popov :
> On Mon, May 29, 2023, at 08:05, Máté Kocsis wrote:
> > Hi Everyone,
> >
> > Together with multiple authors, we'd like to start the discussion of the
> > usual
> > deprecation RFC for the subsequent PHP version. You can find the link
> below:
> > https://wiki.php
On Mon, May 29, 2023, at 08:05, Máté Kocsis wrote:
> Hi Everyone,
>
> Together with multiple authors, we'd like to start the discussion of the
> usual
> deprecation RFC for the subsequent PHP version. You can find the link below:
> https://wiki.php.net/rfc/deprecations_php_8_3
>
> Regards:
> Máté
Hello everyone,
On Mon, May 29, 2023 at 6:48 AM Michał Marcin Brzuchalski
wrote:
> So there would be no option to vote on shorthand properties, right?
>
> Array syntax with all properties as strings in quotes probably means no
> support from IDE.
> I think this is a really bad move, I'd be again
On Mon, May 29, 2023, at 6:47 AM, Michał Marcin Brzuchalski wrote:
> Hi Máté,
>
> pon., 29 maj 2023 o 11:18 Máté Kocsis napisał(a):
>
>> Hi Everyone,
>>
>> In the meanwhile, I changed my proposal to use [] instead of {} after the
>> "with" clause due to its better receptance.
>> Additionally, I re
On 29.05.2023 11:18, Máté Kocsis wrote:
Hi Everyone,
In the meanwhile, I changed my proposal to use [] instead of {} after the
"with" clause due to its better receptance.
In "Property name expressions" section's first code example I think you
intended to do `clone $self` (not `clone $this`) i
Hi Máté,
pon., 29 maj 2023 o 11:18 Máté Kocsis napisał(a):
> Hi Everyone,
>
> In the meanwhile, I changed my proposal to use [] instead of {} after the
> "with" clause due to its better receptance.
> Additionally, I removed support for the shorthand "property assignment"
> syntax (clone $this wi
I am not sure if others agree but in my opinion, Global Mersenne Twister
should have been a separate RFC. It has a discussion point that people
might want to discuss on mailing list first.
Hi Everyone,
In the meanwhile, I changed my proposal to use [] instead of {} after the
"with" clause due to its better receptance.
Additionally, I removed support for the shorthand "property assignment"
syntax (clone $this with [property1: "foo"]) in
favor the more powerful one where the left-hand
26 matches
Mail list logo
