Organizing Odin code

preview_player
Показать описание
How Odin's package system works, when I think you should split something into a package and some practical ideas for code organization.

Рекомендации по теме
Комментарии
Автор

One thing I should stress here is that if you make something that is _truly independent_, then by all means, put that in a subfolder (i.e. a package). But if you notice that there are cyclic dependencies and it forces you to change the code outside of your new package, then the package you have created is actually not independent and you're probably heading down the wrong path.

karl_zylinski
Автор

package is a module to solve separate problem or set of problems. packages usually can be easily reused in other projects.

maninblack
Автор

I tend to use packages for namespacing, because I like having different components with their own prefix, and also because I don't like having to prefix procedure names. But I do agree that it creates some friction, as you have to stop to think about how to origanize it such that you don't get cyclic dependencies and whatnot. It can be tricky, but seems doable to me, though I'm not the most experienced person to say it.

skaruts
Автор

Great video. Though I prefer the second method of splitting my code into discreet packages. Mainly because it is what I am used to doing. My programming is quite object based. So much so that the first thing I did with Odin was to make sure I could do 'C' style dynamic dispatch for my game objects 😊
I think you are giving the correct advice though. As the beauty of Odin is it's accessibility and ease of use. Bogging people down with unnecessary code structure limitations will only put them off using what is a great, fun programming language.

scottwilliams
Автор

Hi Karl, thanks for the video and the insights. Do you have a practical example of how you would go about structuring the interface between a game.dll and its platform layer, similar to how Casey does in HMH? From my understanding, you would have to separate it into two packages, since there are two translation units. Would you, in that case, pull out the types for the interface / API into a "common" or just duplicate them on both sides?

leleschneeberger
Автор

Nice video and interesting view on this. I don't know your background but I think that is needed to give little more time to adjust to this way of organization. My background is from go and when I was starting I had the same opinion, but with more experience and revision of seniors codes it just make sence and now I maybe using it too much. There is also difference in go if you want to make something private you need to hide it in directory, there isn't option to make it provate for file.

tomasnevoral
Автор

Interesting, I wonder how this works in much larger projects (e.g. EmberGen). like do they have 1 folder with 200 odin files in there? I guess once you have a very substantial amount of code maybe it's easier to turn parts of it into packages

Mempo
Автор

I am only missing an explanation on what is a library collection and how can I make one. So in in your example you import rl "vendor:raylib" when "vendor:" marks a library collection and I am not finding anywhere how can I make my own library collection?

Edit: I think I found it. It seems when building you can pass a command line parameter which will allow you to use `import "shared:foo"` in your code then.

IgorStojkovic
Автор

Not really convinced by the argument to put everything in a single package to avoid cyclic dependencies. Go has the same constraint and I don't find it a big problem. I think the use of packages to organize code is important and by creating a namespace it avoids naming conventions like entity_foo. Rather define a package entity which defines foo. It becomes accessible elsewhere via import and referenced as entity.foo. Seems pretty clean to me.

roderickmorrison
Автор

As I am back at using odin and raylib, I am using Sublime with it. Is there a way to display function names of the current source file in the side bar? I am so used to navigate inside the code by clickin on function name.

MikeHart
Автор

the least favorite features of Odin.. file name should have suffice to act as namespace.. i would like to explicitly list all the file i want to import and not automatically available to me if its in same package..Zig done this the right way..

_slier