Opaque types/schemas? #656
yamin-oanda
started this conversation in
Ideas
Replies: 2 comments 2 replies
-
OK, I see How about using the export keyword or internal keyword to label an identifier: # config.k
type Env = "test" | "prod"
schema App[_env: Env]:
name: str = "app-${_env}"
app = lambda env: Env -> App {
App(_env = env)
}
internal App # or export app |
Beta Was this translation helpful? Give feedback.
2 replies
-
Just a random watcher here, but I like the idea of being explicit about the visibility of members in public APIs rather than implicit like Python's |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, any plans to introduce opaque types/schemas? I.e. those which may not be directly instantiated from a different module. These can be useful to enforce rules. E.g.,
And the idea is that people must use
config.app("...")
to create instances ofApp
, they can't instantiate it directly withApp { ... }
.This would prevent bypassing the generation of correct
name
values.EDIT: alternatively,
opaque
could allow callingApp(...)
as a function which could save the boilerplate of writing theapp
lambda.Beta Was this translation helpful? Give feedback.
All reactions