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

Reply via email to