Magento 2: qual è lo stato di M2 per quanto riguarda la conformità PSR?

Quindi, secondo la documentazione ufficiale , capisco che Magento 2 è compatibile con PSR-1 e PSR-2.

Mi chiedo se Magento 2 sia (o sarà) conforme agli altri ?

• PSR-3: Logger Interface
• PSR-4: Standard di caricamento automatico
• PSR-6: Interfaccia di memorizzazione nella cache
• PSR-7: interfaccia messaggi HTTP

La risposta che mi aspetto potrebbe anche prendere in considerazione il progetto di PSR

• La PSR-3 è già utilizzata (con Monolog come implementazione predefinita)
• La PSR-4 è già utilizzata (tramite il compositore)
• La PSR-6 non è supportata e non ho intenzione di farlo, ma esiste un'implementazione del bridge: https://github.com/EcomDev/magento-psr6-bridge

• PSR-7 non è supportato e, dato lo stato attuale dei contratti di servizio di richiesta / risposta, è altamente improbabile che lo sia mai.

  Ho provato a costruire un'implementazione di richiesta / risposta compatibile con PSR-7 su un recente Hackathon e ho scoperto che attualmente è impossibile sostituire in modo sano l'implementazione di base. Ne ho parlato con l'architetto capo Anton Kril e ne sono consapevoli, ma il refactoring non è ancora pianificato e sicuramente non accadrà prima di Magento 2.4. Non è rilevante per la maggior parte degli utenti comunque.

Informazioni su eventuali bozze di PSR pertinenti:

• PSR-11 (Container Interop) sarebbe bello da vedere ma temo che il gestore oggetti Magento sia troppo specializzato. Ancora una volta, non conosco piani ed è probabilmente troppo presto per speculare. Aggiornamento: PSR-11 è stato accettato, ma non credo ancora che abbia senso per Magento, tranne se vogliono supportare l'integrazione di pacchetti non Magento forniti con il proprio contenitore DI compatibile con PSR-11.
• Anche PSR-14 (Event Manager) è troppo nuovo per dire qualcosa, ma Magento ne trarrebbe beneficio IMHO. Speriamo che non ci vorranno altri 5 anni per ottenere l'approvazione. Aggiornamento: Nessuna attività riguardante PSR-14 sulla mailing list e Github dal 2016, quindi questo non sembra andare avanti dal dramma di PHP FIG dello scorso anno in cui il gruppo è quasi caduto a pezzi.