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
/// Access level modifier for all generated declarations
publicvaraccess:String="public"
The access property is currently just a string meaning that you can put anything in the config file and we'll end up generating non-functioning code.
CreateAPI will only support public or internal access levels since open can't be applied everywhere and private would just generate code that is unusable. We could model this with an enum instead.
One thing to note is that while we could specify access: internal in the config, we'd want to generate code without access level specifiers (i.e the same as an empty string) since the internal keyword itself in generated code is redundant.
For reference, we've used enums elsewhere before in ConfigOptions so the same pattern can be followed:
Couldn't we just assume one as default and leave the other as a flag? I would assume public, since people most likely will have these as a separate package and then internal can be under isInternalAccess.
It would require deprecating the old access flag though so might be a little tricker than I thought initially as there are a few options to potentially deprecate in the future, we might want a slightly nicer way to manage them.
CreateAPI/Sources/CreateOptions/ConfigOptions.swift
Lines 63 to 64 in baa71af
The
access
property is currently just a string meaning that you can put anything in the config file and we'll end up generating non-functioning code.CreateAPI will only support
public
orinternal
access levels sinceopen
can't be applied everywhere andprivate
would just generate code that is unusable. We could model this with an enum instead.One thing to note is that while we could specify
access: internal
in the config, we'd want to generate code without access level specifiers (i.e the same as an empty string) since theinternal
keyword itself in generated code is redundant.For reference, we've used enums elsewhere before in
ConfigOptions
so the same pattern can be followed:CreateAPI/Sources/CreateOptions/ConfigOptions.swift
Lines 88 to 97 in baa71af
The text was updated successfully, but these errors were encountered: