add docs for usingnamespace #1589
Comments
|
When I look at Zig projects on the internet I have to say that I'm impressed by how little people use the 'use' keyword, I'm the exact opposite and I just can't seem to stop using it. Is it better to prepend every SDL_* function with 'c.' or 'sdl.'? Does that make it clearer where it comes from? The way I have things setup, I can press 't' to instantly go to a symbol. And thanks to zig I can grep for "pub fn NameOfFunction" to find it instantly. Why do I need a path to each symbol spelled out for me? Everyone knows vk, gl, SDL symbols are going to be coming from a single file or a few files someplace. For me, those symbols are clear enough without an explicit path. I take compilation time very seriously. If the lack of 'use' speeds of compilation time, then I may see the point. However, because of namespace per file, it wouldn't surprise me if people write more methods than they would have otherwise so it's easier to (sort of) escape the namespace mechanism: No one's going to be pulling out individual functions (when there's a lot of them), so writing methods is easier. But the act of doing this reduces the compile time penalty from using 'use' and makes it much easier to guess where symbols come from. So it would seem that struct methods are already providing both the ability to reduce compile time and see where symbols come from, making the namespace per file unnecessary in my opinion. Why have a namespace for a file that contains just a single struct? I think I'm in a very small minority here. |
|
@UniqueID1 see also #1047. |
I'm guessing that's due to lack of docs and examples, which isn't entirely unintentional. (Although of course nearer to zig's completion it will not be a valid strategy)
One thing I'll point out is that the common prefix on C functions is essentially a namespace, even though it's part of the symbol name. E.g. One more thing, you can see for the LLVM functions that the self hosted compiler uses, I did this: Lines 26 to 104 in 1c26c2f I can't remember if I opened a proposal for doing something like this automatically or not, but there should at least be a proposal.
Me too. That's the reason for opening #1535, and you can see in the self-hosted compiler I'm going to great lengths to fully utilize all the cores of a machine, cache as much as possible (in memory!), and take advantage of language semantics in order to divide up compilation into independent work units. I think as that work comes to fruition we can re-evaluate |
|
I had no idea 'use' existed and also have no clue what it actually does and
why it would be related to compile speeds.
So that's the main reason I'm not using it and that probably goes for
others as well.
Op do 27 sep. 2018 05:24 schreef Andrew Kelley <[email protected]>:
… I'm impressed by how little people use the 'use' keyword
I'm guessing that's due to lack of docs and examples, which isn't entirely
unintentional. (Although of course nearer to zig's completion it will not
be a valid strategy)
Is it better to prepend every SDL_* function with 'c.' or 'sdl.'?
One thing I'll point out is that the common prefix on C functions is
essentially a namespace, even though it's part of the symbol name. E.g.
SDL_CreateTexture and SDL.CreateTexture are equivalent in meaning and in
number of characters, but the second example uses an actual namespace.
One more thing, you can see for the LLVM functions that the self hosted
compiler uses, I did this:
https://github.com/ziglang/zig/blob/1c26c2f4d5c9029fe39cc413f75e547636e42a14/src-self-hosted/llvm.zig#L26-L104
I can't remember if I opened a proposal for doing something like this
automatically or not, but there should at least be a proposal.
I take compilation time very seriously.
Me too. That's the reason for opening #1535
<#1535>, and you can see in the
self-hosted compiler I'm going to great lengths to fully utilize all the
cores of a machine, cache as much as possible (in memory!), and take
advantage of language semantics in order to divide up compilation into
independent work units.
I think as that work comes to fruition we can re-evaluate use and the
evolution of the feature.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1589 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AL-sGoC9pBYkGVZPG9EBA8Np1eVu0mBKks5ufETygaJpZM4W5QIJ>
.
|
|
This issue should be renamed to "add docs for usingnamespace" |
might plan to get rid of it?try not to use this feature until it becomes stable.The text was updated successfully, but these errors were encountered: