Align order of constructor arguments of Index and UniqueConstraint #6820

New Issue

admin · 2026-01-22T15:39:26+01:00

admin commented

2026-01-22 15:39:26 +01:00

Originally created by @ThomasLandauer on GitHub (Sep 2, 2021).

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	Don't know

Summary

Signature of Index::__construct():

public function __construct($columns, $fields, $name, ...)

Signature of UniqueConstraint::__construct()

public function __construct($name, $columns, $fields, ...)

I'm suggesting to make the order consistent.

Originally created by @ThomasLandauer on GitHub (Sep 2, 2021). ### Feature Request | Q | A |------------ | ------ | New Feature | yes | RFC | no | BC Break | Don't know #### Summary Signature of [`Index::__construct()`](https://github.com/doctrine/orm/blob/3.0.x/lib/Doctrine/ORM/Mapping/Index.php): ```php public function __construct($columns, $fields, $name, ...) ``` Signature of [`UniqueConstraint::__construct()`](https://github.com/doctrine/orm/blob/3.0.x/lib/Doctrine/ORM/Mapping/UniqueConstraint.php) ```php public function __construct($name, $columns, $fields, ...) ``` I'm suggesting to make the order consistent.

admin closed this issue

2026-01-22 15:39:27 +01:00

admin commented

2026-01-22 15:39:28 +01:00

@derrabus commented on GitHub (Sep 5, 2021):

Can you elaborate what problem this change would solve?

@derrabus commented on GitHub (Sep 5, 2021): Can you elaborate what problem this change would solve?

admin commented

2026-01-22 15:39:28 +01:00

@ThomasLandauer commented on GitHub (Sep 6, 2021):

When looking at the attributes, the switched order is inconsistent and therefore confusing:

#[ORM\UniqueConstraint(name: 'user_foo', fields: ['foo'])]
#[ORM\Index(fields: ['bar'], name: 'user_bar')]
class User

Especially since a UniqueConstraint is in fact just a special case of an Index.
I know that you can change the order in the declaration, but then the IDE keeps complaining that they don't match the parameter order ;-)
Would it be a big change to switch them?

@ThomasLandauer commented on GitHub (Sep 6, 2021): When looking at the attributes, the switched order is inconsistent and therefore confusing: ```php #[ORM\UniqueConstraint(name: 'user_foo', fields: ['foo'])] #[ORM\Index(fields: ['bar'], name: 'user_bar')] class User ``` Especially since a `UniqueConstraint` is in fact just a special case of an `Index`. I know that you can change the order in the declaration, but then the IDE keeps complaining that they don't match the parameter order ;-) Would it be a big change to switch them?

admin commented

2026-01-22 15:39:28 +01:00

@derrabus commented on GitHub (Sep 6, 2021):

I know that you can change the order in the declaration,

Exactly. The point of named arguments is that the order does not matter anymore.

but then the IDE keeps complaining that they don't match the parameter order ;-)

Well, that's a PhpStorm issue. You don't have to adhere to that inspection and you can disable it. There's nothing wrong with using a different order here, so PhpStorm must not raise a flag here imho.

See also https://youtrack.jetbrains.com/issue/WI-62252

Would it be a big change to switch them?

Well, now that we've shipped a stable version already, changing the order of the constructor arguments would mean a breaking change for constructor calls with ordered arguments. To my knowledge, the order of arguments was never documented, so the impact is probably low. But still, people might have relied on it.

And that is basically why I asked for the problem that should be solved here. If we consider a BC break, we should be aware of why we're doing this.

@derrabus commented on GitHub (Sep 6, 2021): > I know that you can change the order in the declaration, Exactly. The point of named arguments is that the order does not matter anymore. > but then the IDE keeps complaining that they don't match the parameter order ;-) Well, that's a PhpStorm issue. You don't have to adhere to that inspection and you can disable it. There's nothing wrong with using a different order here, so PhpStorm must not raise a flag here imho. See also https://youtrack.jetbrains.com/issue/WI-62252 > Would it be a big change to switch them? Well, now that we've shipped a stable version already, changing the order of the constructor arguments would mean a breaking change for constructor calls with ordered arguments. To my knowledge, the order of arguments was never documented, so the impact is probably low. But still, people might have relied on it. And that is basically why I asked for the problem that should be solved here. If we consider a BC break, we should be aware of why we're doing this.

admin commented

2026-01-22 15:39:28 +01:00

@ThomasLandauer commented on GitHub (Sep 6, 2021):

Well, since named arguments are new (PHP 8), there are no established best practices yet. Deviating from the original order might be a no-go in 5 years - or common sense ;-)
If you change it now, it is some work; if you change it in 5 years, it is much work. If you keep it forever, it is zero work ;-)

I have too little insight, just decide either way, and feel free to close this issue...

@ThomasLandauer commented on GitHub (Sep 6, 2021): Well, since named arguments are new (PHP 8), there are no established best practices yet. Deviating from the original order might be a no-go in 5 years - or common sense ;-) If you change it now, it is *some* work; if you change it in 5 years, it is *much* work. If you keep it forever, it is *zero* work ;-) I have too little insight, just decide either way, and feel free to close this issue...

admin commented

2026-01-22 15:39:29 +01:00

@derrabus commented on GitHub (Sep 7, 2021):

I think I'd like to hear @beberlei's point of view here.

@derrabus commented on GitHub (Sep 7, 2021): I think I'd like to hear @beberlei's point of view here.

admin commented

2026-01-22 15:39:30 +01:00

@ThomasLandauer commented on GitHub (Feb 12, 2024):

Implemented in https://github.com/doctrine/orm/pull/10964 :-)

@ThomasLandauer commented on GitHub (Feb 12, 2024): Implemented in https://github.com/doctrine/orm/pull/10964 :-)

admin referenced this issue

2026-01-22 16:06:37 +01:00