Consider PHP 7.2 for ORM.NEXT #5591

Closed
opened 2026-01-22 15:12:16 +01:00 by admin · 11 comments
Owner

Originally created by @Majkl578 on GitHub (Jun 27, 2017).

Primary motivation:

  • object typehint
    • should eliminate lots of mixed types across whole code base
    • greatly improving type safety & avoid potential mixed-related bugs
    • clean-up public API
    • less BC breaks in future versions
  • parameter type widening
    • could ease migration
    • mostly theoretical benefitl? (added return types will still break user-land things)

As an example, here's how EntityManagerInterface would look for 7.2. ☺️

PHP 7.2 is due to release before the end of year. There's already alpha 2 (without object typehint - should arrive in alpha 3 / beta 1).

Thoughts?

Originally created by @Majkl578 on GitHub (Jun 27, 2017). Primary motivation: * [**object** typehint](https://wiki.php.net/rfc/object-typehint) * should eliminate lots of mixed types across whole code base * greatly improving type safety & avoid potential mixed-related bugs * clean-up public API * less BC breaks in future versions * [parameter type widening](https://wiki.php.net/rfc/parameter-no-type-variance) * could ease migration * mostly theoretical benefitl? (added return types will still break user-land things) As an example, [here](https://gist.github.com/Majkl578/9eb51ca704091074c603a732f61f5011)'s how EntityManagerInterface would look for 7.2. ☺️ PHP 7.2 is due to release before the end of year. There's already _alpha 2_ (without object typehint - should arrive in _alpha 3_ / _beta 1_). Thoughts?
admin added the Improvement label 2026-01-22 15:12:16 +01:00
admin closed this issue 2026-01-22 15:12:16 +01:00
Author
Owner

@Ocramius commented on GitHub (Jun 27, 2017):

I think this is more than feasible, and yes, it would allow us to add type hints to interfaces without breaking existing implementations. We just need to enforce the PHP constraint to be ^7.2 there.

Overall 👍

@Ocramius commented on GitHub (Jun 27, 2017): I think this is more than feasible, and yes, it would allow us to add type hints to interfaces without breaking existing implementations. We just need to enforce the PHP constraint to be `^7.2` there. Overall :+1:
Author
Owner

@alcaeus commented on GitHub (Jun 27, 2017):

FWIW, ODM ng (the upcoming 2.0 version) will most likely also require PHP 7.2, so we could let this change trickle down to the common libraries as well.

@alcaeus commented on GitHub (Jun 27, 2017): FWIW, ODM ng (the upcoming 2.0 version) will most likely also require PHP 7.2, so we could let this change trickle down to the common libraries as well.
Author
Owner

@Majkl578 commented on GitHub (Jul 6, 2017):

Initial Doctrine\Common 7.2 migration (for v. 3.x) here: https://github.com/doctrine/common/pull/805

@Majkl578 commented on GitHub (Jul 6, 2017): Initial Doctrine\Common 7.2 migration (for v. 3.x) here: https://github.com/doctrine/common/pull/805
Author
Owner

@Majkl578 commented on GitHub (Jul 22, 2017):

PHP 7.2 is now BETA and Travis added support for it. 🎉

@Majkl578 commented on GitHub (Jul 22, 2017): PHP 7.2 is now BETA and Travis added support for it. 🎉
Author
Owner

@eman1986 commented on GitHub (Aug 15, 2017):

this would be problematic for those who just got PHP 7 support, not everyone is on bleeding edge, just a thought.

@eman1986 commented on GitHub (Aug 15, 2017): this would be problematic for those who just got PHP 7 support, not everyone is on bleeding edge, just a thought.
Author
Owner

@alcaeus commented on GitHub (Aug 15, 2017):

That is ok. If they are not on bleeding edge php, they most likely won’t want to be on bleeding edge ORM either.

@alcaeus commented on GitHub (Aug 15, 2017): That is ok. If they are not on bleeding edge php, they most likely won’t want to be on bleeding edge ORM either.
Author
Owner

@Ocramius commented on GitHub (Aug 15, 2017):

Pretty much what @alcaeus said: if you are developing new software, the target stable version should be the current one. If you are maintaining existing software, you are perfectly ok with using stable dependencies that won't get new shiny features, yet will receive security updates.

@Ocramius commented on GitHub (Aug 15, 2017): Pretty much what @alcaeus said: if you are developing new software, the target stable version should be the current one. If you are maintaining existing software, you are perfectly ok with using stable dependencies that won't get new shiny features, yet will receive security updates.
Author
Owner

@eman1986 commented on GitHub (Aug 15, 2017):

True, though some people are stuck on web hosts that restrict their version. My webhost just got me on PHP 7, and they probably won't have 7.1 until next year. I'd love to work with 7.1, but my production environment prevents that unfortunately and I don't feel like babysitting my own server.

@eman1986 commented on GitHub (Aug 15, 2017): True, though some people are stuck on web hosts that restrict their version. My webhost just got me on PHP 7, and they probably won't have 7.1 until next year. I'd love to work with 7.1, but my production environment prevents that unfortunately and I don't feel like babysitting my own server.
Author
Owner

@Ocramius commented on GitHub (Aug 15, 2017):

That's perfectly ok, but on the counter side, we aren't babysitting your
hosting provider either

On 15 Aug 2017 7:54 PM, "Ed Lomonaco" notifications@github.com wrote:

True, though some people are stuck on web hosts that restrict their
version. My webhost just got me on PHP 7, and they probably won't have 7.1
until next year. I'd love to work with 7.1, but my production environment
prevents that unfortunately and I don't feel like babysitting my own server.


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6529#issuecomment-322540095,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakMly0bmvET0FPQALz9QruzfNfwDsks5sYdtmgaJpZM4OGEyg
.

@Ocramius commented on GitHub (Aug 15, 2017): That's perfectly ok, but on the counter side, we aren't babysitting your hosting provider either On 15 Aug 2017 7:54 PM, "Ed Lomonaco" <notifications@github.com> wrote: True, though some people are stuck on web hosts that restrict their version. My webhost just got me on PHP 7, and they probably won't have 7.1 until next year. I'd love to work with 7.1, but my production environment prevents that unfortunately and I don't feel like babysitting my own server. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/doctrine/doctrine2/issues/6529#issuecomment-322540095>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakMly0bmvET0FPQALz9QruzfNfwDsks5sYdtmgaJpZM4OGEyg> .
Author
Owner

@eman1986 commented on GitHub (Aug 16, 2017):

fair enough, I said my piece :)

@eman1986 commented on GitHub (Aug 16, 2017): fair enough, I said my piece :)
Author
Owner

@Majkl578 commented on GitHub (Nov 30, 2017):

Merged into develop in 9f5fd3713fa0c8f34a47519ea78d2a6337d65a22.

@Majkl578 commented on GitHub (Nov 30, 2017): Merged into develop in 9f5fd3713fa0c8f34a47519ea78d2a6337d65a22.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5591