You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#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:
return value // return the userId if there is one stored
}
returnrepository[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
The text was updated successfully, but these errors were encountered:
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
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 theComputedKnowledgeSource
orOptionalComputedKnowledgeSource
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:SpeziAccount/Sources/SpeziAccount/AccountValue/Keys/UserIdKey.swift
Lines 142 to 152 in 6b38140
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 thecompute
implementation. It doesn't need to be generic, as it is strongly typed to theAccountStorage
.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
The text was updated successfully, but these errors were encountered: