Doctrine Common
  1. Doctrine Common
  2. DCOM-189

Doctrine Proxies may conflict with interfaced constructors

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.5.0
    • Component/s: None
    • Labels:
      None

      Description

      The Doctrine ProxyGenerator generates for a proxy a constructor. The documentation of Doctrine states that the constructor is never called. For a project, I created a group of entities with a interfaced constructor in order to enforce a common interface. This results in a incompatible proxy and so a fatal error.

        Activity

        Hide
        Marco Pivetta added a comment -

        Re-opening.

        While interfaced constructors are a known bad practice, changing constructor parameters is also a well known LSP violation (a minor one).

        I'll keep tracking this, but I'm blocked by HHVM's missing Closure::bind() as of https://github.com/facebook/hhvm/issues/1203

        Show
        Marco Pivetta added a comment - Re-opening. While interfaced constructors are a known bad practice, changing constructor parameters is also a well known LSP violation (a minor one). I'll keep tracking this, but I'm blocked by HHVM's missing Closure::bind() as of https://github.com/facebook/hhvm/issues/1203
        Hide
        Guilherme Blanco added a comment -

        Creating interfaces with __construct ties your contract preventing extensibility points. This is nature of OOP and I do not consider this should be documented because it's (in-theory) expected that people have some level of knowledge in OO design when coding.

        Closing this as invalid.

        Show
        Guilherme Blanco added a comment - Creating interfaces with __construct ties your contract preventing extensibility points. This is nature of OOP and I do not consider this should be documented because it's (in-theory) expected that people have some level of knowledge in OO design when coding. Closing this as invalid.
        Hide
        Marco Pivetta added a comment -

        I actually had more requests for this feature on a similar project ( https://github.com/Ocramius/ProxyManager/issues/115 ).
        I will mark this as feature request, but can't guarantee that it will get into Doctrine 2.x, since it may be a BC break.

        Show
        Marco Pivetta added a comment - I actually had more requests for this feature on a similar project ( https://github.com/Ocramius/ProxyManager/issues/115 ). I will mark this as feature request, but can't guarantee that it will get into Doctrine 2.x, since it may be a BC break.
        Hide
        Harmen M added a comment -

        Ok, then I change my implementation.

        But, maybe it is an idea to update the documentation of the ORM and state that constructor interfacing is not possible?
        http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/architecture.html

        Show
        Harmen M added a comment - Ok, then I change my implementation. But, maybe it is an idea to update the documentation of the ORM and state that constructor interfacing is not possible? http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/architecture.html
        Hide
        Benjamin Eberlei added a comment -

        Adding __construct to an interface is an anti pattern and shouldn't be done.

        Show
        Benjamin Eberlei added a comment - Adding __construct to an interface is an anti pattern and shouldn't be done.
        Hide
        Marco Pivetta added a comment -

        Harmen M why do you have a constructor in an interface? That's a very bad practice, and it makes things quite hard to handle.

        I can think of a workaround, but I first want to be sure there's a real advantage in changing the current implementation to use

        unserialize()

        just to handle this specific use case.

        Show
        Marco Pivetta added a comment - Harmen M why do you have a constructor in an interface? That's a very bad practice, and it makes things quite hard to handle. I can think of a workaround, but I first want to be sure there's a real advantage in changing the current implementation to use unserialize() just to handle this specific use case.
        Hide
        Harmen M added a comment -

        Edit: added the correct description. I accidentially submitted the form before editing the description.

        Show
        Harmen M added a comment - Edit: added the correct description. I accidentially submitted the form before editing the description.
        Hide
        Marco Pivetta added a comment -

        Cannot fix this - the constructor is required to override instantiation logic

        Show
        Marco Pivetta added a comment - Cannot fix this - the constructor is required to override instantiation logic

          People

          • Assignee:
            Marco Pivetta
            Reporter:
            Harmen M
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: