Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

2021-12-31 Thread Kirill Nesmeyanov
>Пятница, 31 декабря 2021, 10:20 +03:00 от Christian Schneider 
>:
> 
>Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov < n...@xakep.ru >:
>> I support this behavior fix because in its current form, due to a similar 
>> problem (almost?), all PSR-7 implementations contain bugs that violate 
>> RFC7230 (section 3.2:  
>> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus, 
>> physically, by the standard, all headers can have the name "0" (like «0: 
>> value»), but when stored inside implementations, it is converted to a string 
>> and a problem arises ($message->getHeaders() // returns array> string> instead of array).
>>
>> To solve this problem without BC, it seems to me that Nikita's idea with 
>> «declares» is most suitable, like:
>> ```
>> > declare(strict_types=1, strict_array_keys=1);
>>
>> $array["0"] = 42; // array(1) { string(1) "0" => int(42) }
>> ```
>
>I probably sound like a broken record but I'd strongly advise against it as it 
>creates language dialects which means a line like
>$a["0"] = 42;
>behaves differently depending on context, e.g. copying code from Stackoverflow 
>might lead to subtle bugs and reminds me way too much of the ini-settings 
>magic_quotes_gpc.
>
>My take is that changing behavior is ok if it can go through a 
>deprecation/warning phase but that is IMHO not the case here.
>
>If people want to have different behavior I'd rather have a new type like
>$a = new Dict;
>$a["0"] = 42;
>possibly with a short-hand for initialization.
>
>Regards,
>- Chris
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit:  https://www.php.net/unsub.php
 
 
Yep =(
 
In any case, I don't see any other solutions to the problem yet... Well, 
perhaps adding the Map and Set objects like in ur example.
 
On the other hand, probably we can forget about the BC and still fix it in 
major release. I don't think that anyone really uses such functionality and 
this is part of the real business logic. This is what I personally would 
prefer. Then this will automatically fix all PSR-7 implementations, and I hope 
there is a lot of code where such a case with automatic type conversion is not 
taken into account.
 
--
Kirill Nesmeyanov
 

Re: [PHP-DEV] Surveying interest regarding CMake

2021-12-31 Thread Pierre Joye
good evening Horváth,

On Thu, Dec 30, 2021, 11:49 PM Horváth V.  wrote:

> Like I said in another e-mail, I wish to work on my host OS and this is
> something that would need to be done either way. It won't take me long
> either and PHP has been chugging along nicely so far without CMake.
>
> vcpkg has more dependencies missing than Conan and Conan has the
> advantage of providing pre-built binaries. For vcpkg, Open LDAP is
> missing, Cyrus SASL is missing, Bison is missing, Flex is missing, etc.
>

excellent,  Conan it is then  :)




> After New Year's, I will get to grinding out the dependencies that are
> missing in Conan and depending on how fast my PRs are accepted to CCI, I
> may be able to start working on PHP itself in February. Most of the time
> will be taken up by adjusting documentation, PHP provided tooling for
> extensions and gathering feedback from existing extension developers, so
> there is no reason to hurry.
>
> I think I will create a summary issue on the Conan Center Index
> repository with checkboxes to track my progress. Please look forward to
> that and consider subscribing to that issue if you are interested.
>


I will definitely follow it and see what can be done in pickle to support
it as well as the legacy build system.


thank you for pushing it forward, much needed  :)

best,
Pierre