Hi Rowan,
Thank you for the clear technical guidance. I agree we've reached a
consensus that implementing a native Map type would be the proper solution
to this long-standing issue.
To move forward, I'd like to clarify a few practical aspects:
1. **RFC Proposal**
- Should I initiate an RFC draft at this stage?
- If yes, would you recommend starting with an "idea" thread on
internals@lists.php.net first?
2. **Implementation Resources**
- Given my limited experience with PHP core development:
- What would be the minimal viable prototype to demonstrate
feasibility?
- Are there active contributors you could refer who might be
interested in collaborating?
3. **Interim Steps**
- Would it help to:
- Compile real-world use cases from major frameworks?
- Benchmark existing userland implementations (e.g., DS\Map)?
I'm committed to driving this improvement and willing to coordinate
non-code efforts. Your advice on the most effective next steps would be
invaluable.
Best regards,
[xiaoma]
Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> 于2025年5月29日周四 00:43写道：
>
>
> On 28 May 2025 14:42:01 BST, "马正强" <a766650...@gmail.com> wrote:
>
> > First, we could add a parameter like preserve_key_types to array
> > functions such as array_keys()/array_search() to temporarily handle the
> > implicit conversion issue.
>
>
> This will not help. The keys are changed when they are *written* to the
> array, not when they are read back out. No option to array_keys can tell
> you whether the key 42 was originally set as '42', because that information
> is not stored anywhere.
>
>
>
> > Alternatively, we could introduce a new data type "Map"
>
> Yes, I think this was suggested a couple of times on the previous thread.
> It would be a useful feature, but probably not easy to implement
> efficiently and integrate thoroughly into the language.
>
>
> Regards,
> Rowan Tommins
> [IMSoP]
>
