Skip to content

IBX-11959: Added getters to Translation Message and Plural value objects - #795

Open
tbialcz wants to merge 2 commits into
6.0from
IBX-11959-add-translation-getters
Open

IBX-11959: Added getters to Translation Message and Plural value objects#795
tbialcz wants to merge 2 commits into
6.0from
IBX-11959-add-translation-getters

Conversation

@tbialcz

@tbialcz tbialcz commented Jul 31, 2026

Copy link
Copy Markdown
Contributor
🎫 Issue IBX-11959

Description:

Added getters to Message and Plural translation value objects, so consumers don't have to rely on magic ValueObject::__get property access (which PHPStan flags). ValidationError::getTranslatableMessage() now declares the native return type Message|Plural (all implementations return exactly these two types); implementations covariantly narrow to Message where applicable.

Needed by the follow-up ibexa/user PR for IBX-11959 (ibexa/user#132). No behavior change.

For QA:

No user-facing change, covered by unit tests. End-to-end QA on the ibexa/user PR.

Documentation:

For 6.0.0 release notes: Ibexa\Contracts\Core\FieldType\ValidationError::getTranslatableMessage() return type narrowed from Translation to Message|Plural — third-party implementations declaring Translation must update their signatures. New getters on Message (getMessage(), getValues()) and Plural (getSingular(), getPlural(), getValues()).

@alongosz alongosz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For QA
Internal API only

src/contracts/FieldType/ValidationError.php is definitely not an internal API. Though it doesn't mean that there's something to QA. It's rather something for Doc release notes of 6.0.0

Comment on lines +23 to +25
* @return \Ibexa\Contracts\Core\Repository\Values\Translation\Message|\Ibexa\Contracts\Core\Repository\Values\Translation\Plural
*/
public function getTranslatableMessage(): Translation;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a code smell to me. We're declaring it as strict Translation but then say that we return some other types and in each impl. we define Translation again and say again that it's something else.

Can't covariance/contravariance or templating be used here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

switched to a native Message|Plural return type on the contract, implementations covariantly narrow to Message. Docblocks removed

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it me or this is much worse, why other Translation interfaces implementation cannont be returned now from this method?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you couldn't really return anything else anyway, Translation has only __toString() so everyone checks for Message or Plural to do their job. Subclassing Message/Plural still works

];
}

public function testGetters(): void

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to add to test cases where the current behavior is asserted?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reworked both tests to share the data providers, so getters are now asserted across all existing cases. Not sure it buys us much given the getters just return constructor args, but the coverage doesn't hurt. 🙂

@tbialcz tbialcz added the Doc needed The changes require some documentation label Jul 31, 2026
@tbialcz
tbialcz requested a review from alongosz July 31, 2026 12:08
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Doc needed The changes require some documentation Ready for review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants