Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

Hello, I read about this extension times ago but didn't know whether it had been public. If Nikita is reading this, I request him to think of proposing a modified version of this extension bundled with PHP. In simple words, he can hide the function that registers a class that serves as a prototype

Re: [PHP-DEV] Using clang-analyzer with PHP: experiences?

Good point, but I'm still on GCC 10 in Fedora. I haven't tried its static analyzer yet either. That said, I don't know how GCC's analyzer handles PHP's ewhateveralloc functions - that is, if it'd do better than LLVM. On Tue, 2021-05-25 at 23:43 +0100, G. P. B. wrote: > Isn't this handled by the GC

Re: [PHP-DEV] Using clang-analyzer with PHP: experiences?

On Tue, 25 May 2021 at 21:10, Calvin Buckley wrote: > I did some additional research and seemed to have decent luck with > slamming a construct like this after the includes: > > #define emalloc malloc > #define erealloc realloc > #define ecalloc calloc > #define estrdup strdup > #define estrnd

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

Hi all, It sounds like scalar objects by Nikita: https://github.com/nikic/scalar_objects Regards, Iván Arias. Get Outlook for Android __

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

Hello. > > ```php > $array|>map($fn1, ?)|>filter(?, $fn2); > $array->map($fn1)->filter($fn2); > ``` > Whitespace removal is not a solution for code length problems. You might have a new problem if you do it. "|" is very similar to the lowercase "L" and uppercase "i". It's just an extra 3 charact

Re: [PHP-DEV] Disable autovivification on false

On May 25, 2021, at 09:23, Kamil Tekiela wrote: > I'd like to start a discussion on the following RFC > https://wiki.php.net/rfc/autovivification_false > Particularly, I am looking for opinions on whether this behaviour should be > left alone, should be disabled on false, or should be disabled on

Re: [PHP-DEV] Using clang-analyzer with PHP: experiences?

I did some additional research and seemed to have decent luck with slamming a construct like this after the includes: #define emalloc malloc #define erealloc realloc #define ecalloc calloc #define estrdup strdup #define estrndup strndup #define efreefree One could wrap it around `__clang_

Re: [PHP-DEV] Disable autovivification on false

On Tue, May 25, 2021 at 11:23 AM Kamil Tekiela wrote: > I'd like to start a discussion on the following RFC > https://wiki.php.net/rfc/autovivification_false > Particularly, I am looking for opinions on whether this behaviour should be > left alone, should be disabled on false, or should be disab

Re: [PHP-DEV] Disable autovivification on false

>In any case, the removing of the autovivification behaviour MUST be preceded by a period of deprecation notices. Yeah, obviously. Sorry I didn't make it clear in the RFC. I clarified this now. The goal is to first determine if we should restrict this behaviour or not.

Re: [PHP-DEV] Disable autovivification on false

> Le 25 mai 2021 à 18:23, Kamil Tekiela a écrit : > > Hi Internals, > > I'd like to start a discussion on the following RFC > https://wiki.php.net/rfc/autovivification_false > Particularly, I am looking for opinions on whether this behaviour should be > left alone, should be disabled on false,

Re: [PHP-DEV] Disable autovivification on false

Am 25.05.2021 um 18:23 schrieb Kamil Tekiela : > I'd like to start a discussion on the following RFC > https://wiki.php.net/rfc/autovivification_false > Particularly, I am looking for opinions on whether this behaviour should be > left alone, should be disabled on false, or should be disabled on nu

[PHP-DEV] Disable autovivification on false

Hi Internals, I'd like to start a discussion on the following RFC https://wiki.php.net/rfc/autovivification_false Particularly, I am looking for opinions on whether this behaviour should be left alone, should be disabled on false, or should be disabled on null and false, and left only for undefine

[PHP-DEV] Re: [RFC] [Draft] Add Randomizer class (before: Add RNG extension)

Hi, Thanks for the response. The RFC has been revised based on the points you pointed out. https://wiki.php.net/rfc/rng_extension The main changes are as follows: - Class name has been changed from `Randomizer` to `Random` . - Added a static method `getNonBiasedMax()` to get the safe range. - `

Re: [PHP-DEV] Allow combining arg unpacking and named args

On Tue, May 25, 2021 at 4:36 PM Levi Morrison wrote: > On Tue, May 25, 2021 at 8:18 AM Nikita Popov wrote: > > > > Hi internals, > > > > Currently, argument unpacking (...$foo) cannot be combined with named > > arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y, > > ...$args

Re: [PHP-DEV] [RFC] [Draft] Add Randomizer class (before: Add RNG extension)

Hi Go, On Sat, 22 May 2021 at 21:57, Go Kudo wrote: > > If I have left anything out, please let me know. I guess the RFC is still being drafted, but some bits are still quite unclear, particularly whether the proposal includes deprecating existing functions. My suggestion would be to not deprec

Re: [PHP-DEV] Allow combining arg unpacking and named args

On Tue, May 25, 2021 at 8:18 AM Nikita Popov wrote: > > Hi internals, > > Currently, argument unpacking (...$foo) cannot be combined with named > arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y, > ...$args) are rejected by the compiler. > > https://github.com/php/php-src/pu

Re: [PHP-DEV] Re: Bugsnet

Hi Stas, On Sun, May 9, 2021, 3:06 PM Stanislav Malyshev wrote: > Hi! > > > If at some time in the future, github becomes a less than suitable > > environment for us, we can just move, no problem. There's no sense in > > which we are locked into anything. > > I don't see how we could "just move"

[PHP-DEV] Allow combining arg unpacking and named args

Hi internals, Currently, argument unpacking (...$foo) cannot be combined with named arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y, ...$args) are rejected by the compiler. https://github.com/php/php-src/pull/7009 relaxes this by allowing func(...$args, x: $y). The named a

Re: [PHP-DEV] Re: Bugsnet

On Tue, May 25, 2021 at 3:10 PM Christoph M. Becker wrote: > On 25.05.2021 at 14:57, Nikita Popov wrote: > > > To make some forward progress here, I think a good starting point would > be > > to enable GitHub issues on the doc-* repos to get some usage experience > in > > a more limited setting.

Re: [PHP-DEV] [RFC] First-class callable syntax

On Fri, May 21, 2021 at 10:08 AM Rowan Tommins wrote: > > Everyone: please let's keep this thread for talking about first-class > callables, and focus on the semantics not just the syntax - are there > edge cases we need to consider, downsides to the proposed > implementation, etc? > Well the se

[PHP-DEV] HTTP Early Hint support

Hi internals, Currently, PHP only supports sending one set of headers. HTTP 1xx status codes may require sending multiple sets of headers. In particular, to use 103 Early Hints you need to first send Link headers for early hints, and then, once your actual response is ready, send the usual 200/wha

Re: [PHP-DEV] Re: Bugsnet

On 25.05.2021 at 14:57, Nikita Popov wrote: > To make some forward progress here, I think a good starting point would be > to enable GitHub issues on the doc-* repos to get some usage experience in > a more limited setting. Docs issues probably benefit more from being hosted > on GitHub than php-s

Re: [PHP-DEV] Re: Bugsnet

On Mon, May 10, 2021 at 11:22 PM Christoph M. Becker wrote: > On 10.05.2021 at 17:10, Nikita Popov wrote: > > > * As was already mentioned, there's no support for security issues, so > > we'd retain bugs.php.net for that purpose, at least for the time being. > > But even if bugsnet would no long

Re: [PHP-DEV] [RFC] First-class callable syntax

On Fri, May 21, 2021 at 11:09 AM Andreas Leathley wrote: > [...] > > About the bikeshedding: Using "..." as a symbol does make sense to me, > as variadic unpacking/variadic arguments have a similar connotation > (referring to an unknown/arbitrary amount of elements). * was also > suggested (as in

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

On 25.05.2021 12:40, Karoly Negyesi wrote: > $array->map($fn1)->filter($fn2) > > 1. It's longer. Much longer. > 2. It still requires knowing where the array goes. That's legacy which we > could sidestep with the arrow notation. > 3. Admittedly, the pipe is much more powerful. I agree. A unified o

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

> The proposed syntax > > $array |> array_map($fn1, ?) |> array_filter(?, $fn2) > > When I compare to: > > $array->map($fn1)->filter($fn2) > > 1. It's longer. Much longer. > 2. It still requires knowing where the array goes. That's legacy which we > could sidestep with the arrow notation. > 3. Adm

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

Thanks for your quick feedback everyone. On Tue, May 25, 2021 at 3:22 AM someniatko wrote: > > The pipe operator feels like a poor solution while `->` would do exactly > what people want. > > Could you elaborate? Adding method-like array access functions with > only few predefined functions, and

Re: [PHP-DEV] [RFC] First-class callable syntax

Le ven. 21 mai 2021 à 16:31, Larry Garfield a écrit : > On Fri, May 21, 2021, at 2:52 AM, Nicolas Grekas wrote: > > Sorry for self-reply, this needs some clarifications :) > > > > Le ven. 21 mai 2021 à 09:17, Nicolas Grekas < > nicolas.grekas+...@gmail.com> > > a écrit : > > > > >> There's been a

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

> The pipe operator feels like a poor solution while `->` would do exactly what > people want. Could you elaborate? Adding method-like array access functions with only few predefined functions, and only for arrays looks very limited in scope, while the pipe operator would allow applying any exist

Re: [PHP-DEV] Bug with str_replace

On Tue, May 25, 2021 at 12:13 PM Eugene Sidelnyk wrote: > When use str_replace with arrays there's strange behavior > > https://3v4l.org/maNqa > > > ```php > var_dump(str_replace( > [ > ',', > '.', > ],[ > '.', >

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

Heyo, On Tue, May 25, 2021 at 11:20 AM Karoly Negyesi wrote: > Hi, > > I was wondering whether $array->map($somefunction) would be possible. I am > not a C programmer by any stretch but reading ZEND_VM_HOT_OBJ_HANDLER(112 > it seems to me it should be quite easy (famous last words) to find out i

[PHP-DEV] Bug with str_replace

When use str_replace with arrays there's strange behavior https://3v4l.org/maNqa ```php var_dump(str_replace( [ ',', '.', ],[ '.', ',', ], '1.2,3' )); ``` This code is expecte

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

On Tue, May 25, 2021 at 11:31 AM Hans Henrik Bergan wrote: > fwiw this can be implemented in userland, and i bet someone already made a > composer package for it ^^ > Not everyone is interested in doing `$array = new ArrayWrapper($originalArray)` and then breaking all `array` parameters. There a

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

Sorry, I made a typo here. In combination with the proposed Partial Function Application RFC (https://wiki.php.net/rfc/partial_function_application), which is however is under active discussion, and changes will probably be made to it, it would look roughly like this: ```php $array |> array_map($s

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

> I was wondering whether $array->map($somefunction) would be possible. There is Pipe Operator RFC existing already, which most probably would suit your needs. The code you want will look like this: https://wiki.php.net/rfc/pipe-operator-v2 ```php $array |> array_map($somefunction). ``` Best wis

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

fwiw this can be implemented in userland, and i bet someone already made a composer package for it ^^ On Tue, 25 May 2021 at 11:20, Karoly Negyesi wrote: > Hi, > > I was wondering whether $array->map($somefunction) would be possible. I am > not a C programmer by any stretch but reading ZEND_VM_H

[PHP-DEV] A little syntactic sugar on array_* function calls?

Hi, I was wondering whether $array->map($somefunction) would be possible. I am not a C programmer by any stretch but reading ZEND_VM_HOT_OBJ_HANDLER(112 it seems to me it should be quite easy (famous last words) to find out if object is an array and if so then 1. prepend the string array_ before