Introducing Internal Modules to V about v HOT 10 CLOSED

Many people think it's unnecessary. I feel like we should copy Go's behavior and allow internal modules. Easy to do by just comparing the name to internal.

from v.

Actually, the only thing public by default in a V module is the module name. All structs, fields in structs, receiver methods, constants, functions, etc. must be marked with the pub keyword to make them public (with none of the Go nonsense of the capitalization of the first letter of a name controlling public vs private).

from v.

Actually, the only thing public by default in a V module is the module name. All structs, fields in structs, receiver methods, constants, functions, etc. must be marked with the pub keyword to make them public (with none of the Go nonsense of the capitalization of the first letter of a name controlling public vs private).

That's what I meant by modules being public by default. That means that they can be imported from anywhere. This proposal is to restrict that.

Thanks for your input!

PS: I also prefer the pub keyword over the capitalization used in Go, but that doesn't stop me from coding in Go.

from v.

I code in Go all day at work.

I don't understand the problem of a module name being public. You can import it all day, but if nothing in it is marked public, you can't do anything with it... you just have a "dead" import.

from v.

I code in Go all day at work.

I don't understand the problem of a module name being public. You can import it all day, but if nothing in it is marked public, you can't do anything with it... you just have a "dead" import.

If you work in Go all day, then you know why internal modules exist, right? It is basically the same concept as Go's internal modules.

from v.

Yes, I know they exist, and they do it by directory structure, not keywords.

An import of a path containing the element “internal” is disallowed if the importing code is outside the tree rooted at the parent of the “internal” directory.

Never used them - never saw the need. However, I understand that some might like "hiding" modules. I was mainly responding to your quote that everything in V modules is public, which it isn't. Only the module names are public by default, not the contents.

from v.

Yes, I know they exist, and they do it by directory structure, not keywords.

An import of a path containing the element “internal” is disallowed if the importing code is outside the tree rooted at the parent of the “internal” directory.

Never used them - never saw the need. However, I understand that some might like "hiding" modules. I was mainly responding to your quote that everything in V modules is public, which it isn't. Only the module names are public by default, not the contents.

OK, reading again, I agree that the wording makes it seem that it is all public by default, but what is meant is that the module itself is public, not its contents. If you make something public (struct, function, etc..), then all modules can import it. There is no way of limiting this to only the parent module and sibling modules.

I will change the wording to reflect this.

Thanks once again!

from v.

As for the keyword, it was mainly because when I asked if it was supported in V, someone mentioned it. I don't really care if it uses a directory "internal" or if it uses a keyword. I have only suggested the two ways for discussion.

from v.

Many people think it's unnecessary. I feel like we should copy Go's behavior and allow internal modules. Easy to do by just comparing the name to internal.

Hi, Alex!

I think that'll do. Thanks for your input!

from v.

Better turn this into a GitHub discussion

from v.