Hi, so after some time one of my projects grew larger and I put things into libraries, realizing after a while that I struggle with Capitalization (aaa => Aaa, Aaa => aaa when refactoring). If I capitalize everything, my naming style suffers and it doesn’t feel right at all (though, migh be an option). If I don’t then I can’t make those libraries.
So, no, problem, just decide what’s part of the library and what is not. Then I would not be constantly changing the first letters of names. And what I found out is, that it is not possible to decide what is part of the library and what is not, because whatever landed in there was a component but no library (package).
Things that get bigger might be a component but no library. Folders for components do look nice.
So, since folders are also better than using prefixes (e.g. I find it easier to work with gfx\sprite.go than with gfx_sprite.go along all the other files like snd_explosion.go etc), I decided to change my build script so that it copies all files into one temporary folder before using go. And voila, I can finally use folders. The editor rewrites the paths - no problem.
But copying takes some time and using the build script in the editor is laggier than before. So, moving (move command instead of copy command) the files might be an option. That’s fast. On Windows, I don’t know what symlinks I could make that work like that. Another option: just buy an even faster computer.
Or maybe there is another way? Maybe.. if Go just allowed me to do something? Maybe… some day it allows me to use files that are in a subfolder?
Best regards
PS: Library is what I was thinking of, “package” is what the term would be with Go.
Go has simple rule about using elements from other packages; to do it you need to “export” the symbol (types, functions, variables, …) and to “export” a symbol you have to Capitalize the name.
If you move something in a separate package, you “just” need to remane symbols that should be available outside the package (not everything)
If I capitalize everything, my naming style suffers and it doesn’t feel right at all
I should clarify things. I was doing refactoring. I think I do this a lot.
Moving a name (e.g. struct member) from the main package to another package requires to capitalize it, when it is not already capitalized. And so, when I was refactoring, most friction came from this task. So I considered just using capitalized names everywhere in the main package, too. This would also free me from uncapitalizing names, when I decided that they belong in the main package again - given that those capital letters should indicate what you are working with, not just for making the compiler stop complaining.
I usually don’t know where I should put things at first.
So, this leads to lots of files in one folder, and I assume that is expected to happen. But this is not my style of using file managers / Explorer. I can focus so well when I can open a folder. It looks just nice. I don’t want to give this up or trade it for the renaming friction. Folders are the perfect tool, and IMO seeing them as packages, or seeing packages as folders, is a bit weird. I guess there is a perfect reason for it. But since I am using Go, a systems language, as my desktop language, it wouldn’t make sense for me to search the best answer why things are like this. So I just decided to adapt the build script and the editor to copy files and in effect give me the ability to use subfolders. Well, the build script now is complicated and slow.
It sounds like maybe you need to think carefully about your package design and public surface area. My folder/package structure usually grows organically. Like - recently I had a project where I added an integration with slack, so I created a slack package to abstract that away. Then I needed to integrate with github; so same thing. Each of my packages does one thing and it’s clear from the folder structure what they do.
If you want to have exported types/functions but are worried about not allowing other packages to import them, you could take a look at internal:
In general, I think your problems will mostly go away if you think about package naming/separation of duties before creating your packages. Here are two excellent articles on package naming that might help you (I consider the first one a must read for go developers!):
So, mklink /h source target is the way to create a hard link in Windows. The complication by using different paths for compilation than what you edit won’t go away, but it’s faster. I’ll stick with that unless it gets too frustrating.
Creating packages - maybe, but only when I know I won’t change the structure afterwards. I would do then what Dean_Davidson suggested in order to prevent the bad layout.
Thank you