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

A way to mark symbols as private #84

Open
Akuli opened this issue Jan 19, 2023 · 10 comments
Open

A way to mark symbols as private #84

Akuli opened this issue Jan 19, 2023 · 10 comments

Comments

@Akuli
Copy link
Owner

Akuli commented Jan 19, 2023

Currently all functions and structs are made available for other files to import. There should be a way to make functions and structs be visible only within the current file.

Maybe static?

static def internal_util_function() -> int:
    return 123

static struct PrivateStruct:
    x: int
    y: int

def public_function() -> int:
    return internal_util_function() * 2

struct PublicStruct:
    message: byte*
    line: int
@littlewhitecloud
Copy link
Contributor

littlewhitecloud commented Jan 29, 2023

I think on the contrary, you can use the "extern" keyword to decide which functions need to be exported.
Then other variables, functions, structs of the current file will not be accessed.And then, they will be private

@littlewhitecloud
Copy link
Contributor

def internal_util_function() -> int:
    return 123

static struct PrivateStruct:
    x: int
    y: int

extern def public_function() -> int:
    return internal_util_function() * 2

extern struct PublicStruct:
    message: byte*
    line: int

@Akuli
Copy link
Owner Author

Akuli commented Jan 30, 2023

I think on the contrary, you can use the "extern" keyword to decide which functions need to be exported. Then other variables, functions, structs of the current file will not be accessed.And then, they will be private

So basically, everything is private by default, and you can use a keyword like extern to make public things. This seems like a good idea.

I think I will probably name the keyword public instead of extern, for two reasons:

  • With extern many people would think: "what does the extern keyword do again? Ah now I remember, it makes the thing public."
  • The extern keyword has a different meaning in C. Jou's declare and C's extern both correspond to the same idea: they tell the linker that something exists without defining it.

@Akuli
Copy link
Owner Author

Akuli commented Jan 30, 2023

More possible keywords to use for this:

  • export, same as in JavaScript
  • pub, same as in Rust

@Akuli
Copy link
Owner Author

Akuli commented Feb 1, 2023

  • I think I don't like export, because it would get confused with __declspec(DLLEXPORT) in windows.
  • pub is a bit too short considering Jou's goals: we need readability.

@sumeshir26
Copy link
Contributor

sumeshir26 commented Feb 1, 2023

I think global or public will be the most clear

@Moosems
Copy link

Moosems commented Dec 9, 2023

public looks fine to me. I understood extern just fine and would be a little disappointed if someone couldn't deduce its meaning.

@Akuli
Copy link
Owner Author

Akuli commented Dec 9, 2023

It seems that everyone is happy with public. I will use it when I eventually get around to implementing this :)

@Akuli
Copy link
Owner Author

Akuli commented Dec 25, 2023

How about a decorator?

@public
def add(x: int, y: int) -> int:
    return x + y

@Moosems
Copy link

Moosems commented Dec 29, 2023

I like that, but if it isn't written in Jou that would feel a bit too automagic-y for a decorator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants