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

Macro support for Computed Knowledge Source conformance for AccountKey #64

Open
1 task done
Supereg opened this issue Aug 16, 2024 · 0 comments
Open
1 task done
Labels
enhancement New feature or request

Comments

@Supereg
Copy link
Member

Supereg commented Aug 16, 2024

Problem

#62 introduced the @AccountKey and @KeyEntry macros to simplify the process of defining new account keys. Some account keys need more flexibility and adopt the ComputedKnowledgeSource or OptionalComputedKnowledgeSource protocol.
This can currently done by manually declaring a manual conformance using an extension. However, that exposes the internal name of the generated AccountKey implementation.

Here is an example how such a conformance currently looks like for the userId key:

extension AccountDetails.__Key_userId: ComputedKnowledgeSource {
public typealias StoragePolicy = AlwaysCompute
public static func compute(from repository: AccountStorage) -> String {
if let value = repository.get(Self.self) {
return value // return the userId if there is one stored
}
return repository[AccountKeys.accountId] // otherwise return the primary account key
}
}

Solution

Introduce a more refined approach to introduce this conformance. This is not trivial as Macros generally cannot introduce extensions. However, you can create an attached extension macro (attaching a macro to a type that declares an extension to a protocol). A possible design could look like this.

Create an attached extension macro (e.g., @ComputedKeyExtension). This macro is placed by the @AccountKey macro onto the generated AccountKey type. The @ComputedKeyExtension macro receives a closure that is executed in the compute implementation. It doesn't need to be generic, as it is strongly typed to the AccountStorage.
How the @AccountKey macro decides to generate the additional macro might need some experimentation what works best. Maybe as an additional trailing closure (maybe a bit weird?). Maybe we can also add another macro to the property that the @AccountKey macro could parse, however, this might not be allowed by the Swift macro system.

Additional context

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct and Contributing Guidelines
@Supereg Supereg added the enhancement New feature or request label Aug 16, 2024
@Supereg Supereg changed the title Freestanding Macro for Computed Knowledge Source conformance for AccountKey Macro support for Computed Knowledge Source conformance for AccountKey Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant