On Mon, Jun 2, 2025, at 3:20 AM, 马正强 wrote: > 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]
There's been a fair amount of discussion in the past, and I am 100% in favor of splitting list/sequence, set, and map types into separate types. However, there's some challenges to doing so, mainly around, of course, type variance and generics. See: https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections/#full-reified-generics (The "Collections" section, specifically, and the link to my research document.) Gina is working hard on an associated types RFC ("generics junior"), which would obviate the need for any custom syntax there. That would actually allow doing *most* of the collection implementation in user-space; the missing parts would be operators and being able to use more efficient C implementations. If Gina's RFC passes (it's not yet proposed, unfortunately), I intend to try and write user-space versions to flesh out the design if nothing else. Ideally I'd love for that to turn into an RFC in the future, but the bar for that is of course higher, and we'll have to see what else happens in the mean time. I don't mean to dissuade you from looking into the topic; I just want you to be aware of the prior art so that we don't end up with multiple conflicting half-baked approaches instead of a single fully baked approach. --Larry Garfield