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
It would be really useful to be able to have "private" functions as a concept. This would allow users to write functions that only their codebase should be using, which is very helpful for library datapacks.
I would propose that "private" functions would generate in the private module of the zoglin namespace. For example:
namespace example
module api {
# example:api/public_fn
fn public_fn() {}
# zoglin:private/example/api/private_fn
private fn private_fn() {}
}
Whilst moving it to the Zoglin namespace is a little opaque, I think ultimately the path is still predictable enough for developers.
Zoglin resources should treat private functions as if they are defined in the same spot as a public function.
Accessing variables from a private function probably doesnt need to have this help however, they should refer to the full private path outside of their own function.
Accessing variables between private functions might get confusing from that however, so maybe we need to think more on that.
Every child of a private module will also be private.
The text was updated successfully, but these errors were encountered:
It would be really useful to be able to have "private" functions as a concept. This would allow users to write functions that only their codebase should be using, which is very helpful for library datapacks.
I would propose that "private" functions would generate in the
private
module of the zoglin namespace. For example:Whilst moving it to the Zoglin namespace is a little opaque, I think ultimately the path is still predictable enough for developers.
Zoglin resources should treat private functions as if they are defined in the same spot as a public function.
Accessing variables from a private function probably doesnt need to have this help however, they should refer to the full private path outside of their own function.
Accessing variables between private functions might get confusing from that however, so maybe we need to think more on that.
Every child of a private module will also be private.
The text was updated successfully, but these errors were encountered: