Re: [PHP-DEV] [RFC] Shorter attribute syntax

On Tue, Jun 9, 2020 at 6:57 PM Theodore Brown wrote: > Hi Benjamin, > > On Tue, June 9, 2020 at 6:55 AM Benjamin Eberlei wrote: > > > Larry's suggestion about `#[Attr]` makes an important argument about > > allowing to declare attributes in code in PHP 7 in a forward compatible > > way that has

Re: [PHP-DEV] [RFC] Shorter attribute syntax

Am 09.06.2020 um 17:57 schrieb Theodore Brown: That's an interesting argument. After thinking about it more, though, I'm not sure I understand what the benefit would be. The docblock annotation needed for PHP 7 is *already* forward compatible with PHP 8. So wouldn't this just be duplicating the

[PHP-DEV] Revisiting proposal for addition of `get_class_constants()`

Hi All, With several functions (`str_contains()`, `str_[starts|ends]_with()`) added for PHP8 to make things more clear, it feels like a good time to revisit the multiple requests to add `get_class_constants(string $class): array`. This would allow userland code to retrieve constants in the same

Re: [PHP-DEV] GitHub FPM label

Thanks Stas! On Tue, Jun 9, 2020 at 10:39 PM Stanislav Malyshev wrote: > Hi! > > > Please could someone add an FPM label to github. FPM is a bit on its own > > and the FPM PR's are usually quite independent from other PR's so I think > > it would make sense. Mainly it would help me with

Re: [PHP-DEV] GitHub FPM label

Hi! > Please could someone add an FPM label to github. FPM is a bit on its own > and the FPM PR's are usually quite independent from other PR's so I think > it would make sense. Mainly it would help me with filtering and keeping > track of FPM PR's. Done:

[PHP-DEV] GitHub FPM label

Hi, Please could someone add an FPM label to github. FPM is a bit on its own and the FPM PR's are usually quite independent from other PR's so I think it would make sense. Mainly it would help me with filtering and keeping track of FPM PR's. Thanks Jakub

Re: [PHP-DEV] [RFC] Shorter attribute syntax

Hi Benjamin, On Tue, June 9, 2020 at 6:55 AM Benjamin Eberlei wrote: > Larry's suggestion about `#[Attr]` makes an important argument about > allowing to declare attributes in code in PHP 7 in a forward compatible > way that has not been brought up before. > > ```php > /** @ORM\Entity */ >

Re: [PHP-DEV] [RFC] Shorter attribute syntax

Am 09.06.2020 um 13:55 schrieb Benjamin Eberlei: Larry's suggestion about #[Attr] makes an important argument about allowing to declare attributes in code in PHP 7 in a forward compatible way that has not been brought up before. /** @ORM\Entity */ #[ORM\Entity] class User {} This code would

Re: [PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

wt., 9 cze 2020, 15:33 użytkownik Nikita Popov napisał: > On Tue, May 12, 2020 at 10:26 AM Nikita Popov > wrote: > > > On Wed, Mar 11, 2020 at 10:50 AM Nikita Popov > > wrote: > > > >> Hi internals, > >> > >> Userland classes that implement Traversable must do so either through > >> Iterator

Re: [PHP-DEV] [RFC] Shorter attribute syntax

On Tue, Jun 9, 2020 at 2:07 PM Lynn wrote: > > > On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei > wrote: > >> Larry's suggestion about #[Attr] makes an important argument about >> allowing >> to declare attributes in code in PHP 7 in a forward compatible way that >> has >> not been brought up

[PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

On Tue, May 12, 2020 at 10:26 AM Nikita Popov wrote: > On Wed, Mar 11, 2020 at 10:50 AM Nikita Popov > wrote: > >> Hi internals, >> >> Userland classes that implement Traversable must do so either through >> Iterator or IteratorAggregate. The same requirement does not exist for >> internal

Re: [PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

On Tue, May 12, 2020 at 2:49 PM Sara Golemon wrote: > On Tue, May 12, 2020 at 3:26 AM Nikita Popov wrote: > > // WeakMap::getIterator(): Iterator > > ZEND_METHOD(WeakMap, getIterator) > > { > > if (zend_parse_parameters_none() == FAILURE) { > > return; > > } > >

Re: [PHP-DEV] [RFC] Shorter attribute syntax

+1 On Tue, Jun 9, 2020, 2:56 PM Benjamin Eberlei wrote: > On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown > wrote: > > > Hi internals, > > > > I discussed the syntax for attributes further with Benjamin, Martin, > > and several other internals developers off-list, and with their > > feedback

Re: [PHP-DEV] [RFC] Shorter attribute syntax

On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei wrote: > Larry's suggestion about #[Attr] makes an important argument about allowing > to declare attributes in code in PHP 7 in a forward compatible way that has > not been brought up before. > > /** @ORM\Entity */ > #[ORM\Entity] > class User {}

Re: [PHP-DEV] [RFC] Shorter attribute syntax

On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown wrote: > Hi internals, > > I discussed the syntax for attributes further with Benjamin, Martin, > and several other internals developers off-list, and with their > feedback completed an RFC proposing to use the shorter `@@` syntax > instead of `<<>>`

Re: [PHP-DEV] Numeric Type

Hi all, One thought is that `is_numeric(true)` will return `false`, but the `int` type-hint will accept it as a `1`. The other thought I had was no one mentioned floats, so maybe a `number` type could be argued for but with mixed types that can be solved by `int|float` now. Thanks, Peter On

Re: [PHP-DEV] [VOTE] Attribute Amendments

On 08/06/2020 19:37, Larry Garfield wrote: That... is not related? This is*not* a documentation tool. At all. It's more akin to moving Doctrine Annotations into core (junior version thereof). It doesn't render docblocks redundant, it renders "using docblocks for custom metaprogramming"

Re: [PHP-DEV] What to do with ext/imap?

Le 08/06/2020 à 18:15, Christoph M. Becker a écrit : > Hi all, > > I'm wondering what to do with ext/imap, which uses libc-client which had > its latest release (2007f) in 2011. There is a respective feature > request in the bug tracker () where some > ideas have been

Re: [PHP-DEV] What to do with ext/imap?

We use the extension in several projects, and looking at packagist, all the imap packages use it. I wasn't even aware of the horde imap client mentioned in the link (5 stars on GitHub, not on packagist). I think there should be a long deprecation period before it was removed, which would give

Re: [PHP-DEV] RFC karma

On Tue, Jun 9, 2020 at 9:17 AM Enrico Zimuel wrote: > Hi Internals, > > I'd like to propose an RFC for overriding internal and userland functions. > > The idea came while working on an Application Performance Monitoring (APM) > agent for PHP, where I needed to intercept execution code to provide

[PHP-DEV] RFC karma

Hi Internals, I'd like to propose an RFC for overriding internal and userland functions. The idea came while working on an Application Performance Monitoring (APM) agent for PHP, where I needed to intercept execution code to provide additional information such as execution time. I wrote an