Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the RegistrationBuilder method signatures to use Component and FinalResult rather than [Registration] #24

Open
1 task done
bbrk24 opened this issue Sep 9, 2022 · 0 comments
Labels
enhancement New feature or request good first issue Good for newcomers
Milestone

Comments

@bbrk24
Copy link
Contributor

bbrk24 commented Sep 9, 2022

Checklist

Problem

The documentation for result builders lists the following methods:

  • buildBlock(_ components: Component...) -> Component
  • buildOptional(_ component: Component?) -> Component
  • buildEither(first: Component) -> Component and buildEither(second: Component) -> Component
  • buildArray(_ components: [Component]) -> Component
  • buildExpression(_ expression: Expression) -> Component
  • buildFinalResult(_ component: Component) -> FinalResult

While RegistrationBuilder does technically satisfy these requirements, it does not reference Component or FinalResult directly. If the type aliases are changed, the functions will no longer match.

Feature Request

The static methods of RegistrationBuilder should be updated to reference Component and/or FinalResult as applicable, rather than [Registration]. Additionally, the last overload of buildExpression(_:) (where S.Element == Registration) should be changed to return .init(expression) or return Component(expression), rather than referencing Array explicitly.

In line with these changes, perhaps the method signature of Factory.register(builder:) should be updated as well, to register(@RegistrationBuilder builder: () -> RegistrationBuilder.FinalResult).

Value

This change would put RegistrationBuilder more closely in line with the documentation for result builders, and reduce the amount of work necessary in the future should the types be changed.

@bbrk24 bbrk24 added enhancement New feature or request good first issue Good for newcomers labels Sep 9, 2022
@bbrk24 bbrk24 added this to the Backlog milestone Sep 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant