Why the flat folder structure?
Speiger opened this issue · 5 comments
Question
I am kinda curios.
What made you choose a flat folder structure in the modules?
In this case i am speaking of the "OpenGL" module itself that has a flat folder structure.
What are the upsides compared to a normal folder structure where each extension may receive their own folder for example to make it a bit more structured?
I can't comment on why this structure was chosen, but I wonder why you'd think folders would change anything here. Each OpenGL extension already corresponds to a single file (internally in the templates and the library Java code). For example, the entirety of the AMD_debug_output extension is contained in org.lwjgl.opengl.AMDDebugOutput. Thus, placing extensions in packages would essentially just add a lot of useless packages with just a single class in them.
@TheMrMilchmann while i would agree if there is just a few files that it makes sense to have a flat structure, I could also justify this example where there is enough files where folders could be made with based on what they are.
I think these amount of files justify a "AMD/ARB/EXT/GL/NV/WGL" folder in the first place.
That's why i am asking, why was a flat folder structure made for everything within a module?
Even if subfolders would clean up a lot of it.
The only reason I could see is, it is less work.
Or some java specific reason with native interaction.
Also I don't expect this question to cause a change in LWJGL3.
Maybe in LWJGL4, since that is now in development, but even that is maybe to much of an ask.
But overall I wonder why it was done.
Hey @Speiger,
One reason was compatibility with LWJGL 2. Another reason is it allows the extension classes to access package-private functionality in the GL class.
Moving extension classes to (cross-)vendor-specific packages would indeed be cleaner, but I don't think it's useful in practice. For example, you'd never want to import org.lwjgl.opengl.nv.*. Instead, you usually target specific functionality with import static org.lwjgl.opengl.NVCommandList.*. Auto-completion also works fine with the vendor prefixes.
Hey @Spasi,
Thank you for the answer.
Ok i can see the reason why that is done, and it makes sense.
Though your argument with the imports isn't really one of validity since if the IDE/person doesn't care about the package import percentage but fixed import amounts, which you can obtain easier with a single package then with multiple packages.
Anyways, either side of the argument can be discarded easily, since it is a preference at last.
The reason why i am asking about package folding is actually the browsing experience.
Your suggestion expects that the person already knows everything about the library it is going to use.
But when you are fresh you are bombarded with options and have to take a ton of time to filter what is actually relevant or to find what you are searching for. Assuming you have a rough knowledge of what you are searching.
Not everyone searches with in editor or know what classnames are called at the start of trying things out, but some people search in filetree if that makes sense.
Funnily enough the GL classes are the exact opposite example where they chain on top of each other.
If you know roughly what you search for you pick the highest GL version class search for the one you want and then you change to the GL version class that actually has the thing you want, in terms of fields/functions.
Anyways, even so I kinda did the opposite, I wasn't planning on fighting for a point or a change.
I was just interested for why it was done the way it was done.
Anyways, have a nice week :)
Closing because answered.