Details

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

      Description

      The API could be improved in the next major release:

      • Type::add() instead of addType()
      • Type::isRegistered() instead of hasType() (has sounds weird)

      Etc.. I think the 'type' in the methods is redundant since Type is already the object I am dealing with.

      I'd also like a remove() method to unregister a type at runtime. Would make testing a little easier and I don't have to check with hasType() etc..

        Activity

        Hide
        Steve Müller added a comment -

        API cleanup and staticness can be addressed in 3.0 for the first time. Otherwise we cannot keep BC. You can use Doctrine\DBAL\Types\Type::overrideType('someType', null); as a workaround for removing a type from the registry.

        Show
        Steve Müller added a comment - API cleanup and staticness can be addressed in 3.0 for the first time. Otherwise we cannot keep BC. You can use Doctrine\DBAL\Types\Type::overrideType('someType', null); as a workaround for removing a type from the registry.
        Hide
        Till added a comment -

        I agree on the static. But I'd also like the API to be cleaned up and the remove method.

        Show
        Till added a comment - I agree on the static. But I'd also like the API to be cleaned up and the remove method.
        Hide
        Marco Pivetta added a comment -

        I don't think those namings are really important.
        There's one major change to do, which is to somehow get rid of the staticness of the `Doctrine\DBAL\Types\Type` class, and it is not a simple task.
        It would also be interesting to set the type objects manually, such as a database `password` type that does encryption/decryption based on a given service. That cannot be done without staticness right now, which renders two different connections requiring the same functionality but with different parameters very difficult.

        Show
        Marco Pivetta added a comment - I don't think those namings are really important. There's one major change to do, which is to somehow get rid of the staticness of the `Doctrine\DBAL\Types\Type` class, and it is not a simple task. It would also be interesting to set the type objects manually, such as a database `password` type that does encryption/decryption based on a given service. That cannot be done without staticness right now, which renders two different connections requiring the same functionality but with different parameters very difficult.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Till
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: