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

Module with namespaces #152

Open
hubertpnj opened this issue Oct 20, 2021 · 4 comments
Open

Module with namespaces #152

hubertpnj opened this issue Oct 20, 2021 · 4 comments

Comments

@hubertpnj
Copy link

Is Lobster going to have modules with namespaces (lib.f), or prefixes (lib_f) are here to stay?

@aardappel
Copy link
Owner

There are no plans to change it from _ to ., no. Other than personal preference, any reason?

@Skaruts
Copy link

Skaruts commented Sep 16, 2023

Other than personal preference, any reason?

Doesn't seem to resolve collisions in a meaningful way, and it also makes things from namespaces look like regular identifiers, so you can't tell them apart. Makes code harder to read and to follow.

Also leads to misleading errors:

namespace foo

def derp():
	return 10
import foo

def foo_derp():
	return 200

print(foo_derp())
test.lobster(3): error: double declaration of `foo_derp`
in: def foo_derp():
at:               ^

That's misleading because there are in fact NOT two definitions of foo_derp. There's one of foo_derp, and one of derp, inside a namespace foo. The latter is a distinct definition of foo.derp or foo::derp or foo->derp, or whatever it could be referred as, which imo ought to be anything but foo_derp.

I've just only now started looking at Lobster, so I could be missing something, but it seems to me this could end up leading some users chasing after a definition that doesn't exist, until they realized it's just their function colliding with some lib that they're importing, but the error doesn't make that immediately clear, and the syntax doesn't prevent it.

@aardappel
Copy link
Owner

Since this issue was originally posted, more people have mentioned their dislike for how namespaces use _, so I am indeed considering changing it, but it is an invasive change, so have to see how we can ease in to it.

Another big question is if all the gl_ functions should also become gl. functions, since it is essentially a namespace. That will cause a lot of churn for people.

@aardappel
Copy link
Owner

There's now a poll going on in the Lobster Discord on what namespacing should be like :) https://discord.gg/szJPYdX

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

3 participants