On 2025-03-14 10:09, Juris Evertovskis wrote:
Hello,
I've opened the vote on the Optional interfaces RFC.
https://wiki.php.net/rfc/optional-interfaces
Implementation: https://github.com/php/php-src/pull/17288
Discussion: https://externals.io/message/126185
The voting will be closed on 2025-
Hi Bob
On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand wrote:
>
> On 6.3.2025 23:20:37, Ilija Tovilo wrote:
>
> > I would also like to echo what has been said about the :: operator,
> > which feels out of place. I understand that \ comes with additional
> > autoloading challenges, namely requiring a
On 2025-03-14 16:24, Viktor Khramov wrote:
Hey Juris.
I have a question about this feature.
At the example blow
interface A
{
public function x(Foo $foo);
}
interface B
{
public function x(Bar $foo);
}
class Test implements ?A, ?B
{
}
what would happen if both interfaces existed?
Hi Vi
On 14/03/2025 21:18, Bilge wrote:
Just because some (incompetent) developers cannot grasp proper
escaping should have no bearing whatsoever on language design.
The main problem is not "grasping" it, it's the inconvenience of having
to do it at all, and the "ugliness" (subjective, obviously) o
Hi
Am 2025-03-06 07:23, schrieb Rob Landers:
So, technically, they aren’t required to be in the same RFC; but also,
they complement each other very well.
They really should be separate RFCs then. Your RFC text acknowledges
that in the very first sentence: “two significant enhancements to the
>
> Yeah, this is a Watcher, a periodic function that is called to clean up or
> check something. Yes, it’s a very specific pattern. And of course, the
> Watcher belongs to the service. If the service is destroyed, the Watcher
> should also be stopped.
It’s a Async\Interval, but it behaves ent
Hi Rob
Without looking too deep (yet) into the details, I'm generally in favor of the
idea.
What I'm less in favor of is the implementation choice to expose the inner
class as a property/const and using a fetch mode to grab it.
That feels quite weird to me honestly. How did you arrive at this ch
Hi,
https://wiki.php.net/rfc/optional-interfaces
>
I voted yes as we have got a specific use case in core - user stream
wrapper. More details can be found in
https://github.com/php/php-src/issues/10506 .
Regards
Jakub
Hey Juris.
I have a question about this feature.
At the example blow
interface A
> {
>public function x(Foo $foo);
> }
>
> interface B
> {
>public function x(Bar $foo);
> }
>
> class Test implements ?A, ?B
> {
> }
>
what would happen if both interfaces existed?
пт, 14 мар. 2025 г. в
Hi Dennis,
> This is a late thought, and surely amenable to a later RFC, but I was
> thinking about the get/set path methods and the issue of the / and %2F.
>
> - If we exposed `getPathIterator()` or `getPathSegments()` could we not
> report these in their fully-decoded forms? That is, because t
On Fri, Mar 14, 2025, at 17:09, Ilija Tovilo wrote:
> Hi Bob
>
> On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand wrote:
> >
> > On 6.3.2025 23:20:37, Ilija Tovilo wrote:
> >
> > > I would also like to echo what has been said about the :: operator,
> > > which feels out of place. I understand that
On Sat, Mar 8, 2025, at 09:06, Eugene Sidelnyk wrote:
>>
>
>> The uncoloring of functions in PHP is probably one of the most annoying
>> aspects of fibers, IMHO. It's hard to explain unless you've been using them
>> awhile. But, with colored functions, the caller has control over when the
>>
On Sat, Mar 15, 2025, at 00:21, Rowan Tommins [IMSoP] wrote:
> On 05/03/2025 23:11, Rob Landers wrote:
> >
> > I'd like to introduce my RFC for discussion:
> > https://wiki.php.net/rfc/short-and-inner-classes
>
>
> As a user, I find the concept of inner classes quite confusing.
>
> However, I
On 14 March 2025 23:37:08 GMT, Rob Landers wrote:
>I could get behind `::`, but I feel that it introduces human ambiguity. I
>don't believe it would introduce compiler ambiguity, but as a human, I have to
>hope the programmers are using a style that makes it obvious what are inner
>classes a
Hi,
Depends on there being the intention to have it as parameter type. If it's
> designed to be passed around to functions I really don't want it to be an
> array. I am maintaining a legacy codebase where arrays are being used as
> hashmaps pretty much everywhere, and it's error prone. We lose all
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
On 10 March 2025 03:55:21 GMT, Larry Garfield wrote:
>Support for nested blocks is absolutely mandatory, whatever else we do. If
>you cannot nest one async block (scheduler instance, coroutine, whatever it
>is) inside another, then basically no code can do anything async except the
>top lev
Hey Rob,
On 6.3.2025 00:11:22, Rob Landers wrote:
Hello PHP Internals,
I'd like to introduce my RFC for discussion:
https://wiki.php.net/rfc/short-and-inner-classes
A small note on the Reflection section: it should include a method
giving you an array of all contained ReflectionClasses:
$r
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
Hey Ilija,
On 6.3.2025 23:20:37, Ilija Tovilo wrote:
I would also like to echo what has been said about the :: operator,
which feels out of place. I understand that \ comes with additional
autoloading challenges, namely requiring a fallback autoloading
strategy that currently does not conform to
On Sat, Mar 15, 2025, at 01:01, Rob Landers wrote:
>
>
> On Sat, Mar 15, 2025, at 00:21, Rowan Tommins [IMSoP] wrote:
>> On 05/03/2025 23:11, Rob Landers wrote:
>> >
>> > I'd like to introduce my RFC for discussion:
>> > https://wiki.php.net/rfc/short-and-inner-classes
>>
>>
>> As a user, I fi
On 15.03.2025 at 01:14, Saki Takamachi wrote:
> In the following issue, there was a proposal to add support for scientific
> notation in BCMath.
> https://github.com/php/php-src/issues/17876
>
> I agree with this and have already created a prototype.
> https://github.com/php/php-src/pull/18068
>
Hello, internals.
I created the RFC page for grapheme_levenshtein.
https://wiki.php.net/rfc/grapheme_levenshtein
I would like go to voting at two weeks if any comment is nothing.
If any comment, feel free to comment.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://t
23 matches
Mail list logo
