Ever since you put the Grid* classes in their own folder and created the LevelGrid class, I was wondering if you’d make use of namespaces and/or use the internal keyword to formalize in code the abstraction that it looks like you’re creating.
As the size of the codebase grows it would certainly be helpful to have “built-in” reminders about what should be accessible from where.
Personally, I strongly recommend using namespaces, especially as your project grows.
The internal keyword, though, won’t actually confine accessibility to a namespace, but instead confines scope to a given assembly. As it stands right now, we’re not using Assembly Definitions within any of our courses codebases. This means that all of our scripts are in the Assembly_CSharp assembly. In this context, internal is effectively the same as public.
There are currently no ways in C# to restrict a variable’s scope to a namespace. If another class references the namespace and class, they can access a public (or internal) variable within that namespace (unless that namespace is contained within a different assembly, in which case you can’t access internal objects in another assembly, but you can always access public objects).
Thanks. Coming from Java (from many years ago), I was expecting C# internal was like Java protected. Definitely learned something here.
Yes, I used Java before C# and it took me a bit of research to get my head on straight (in more places than this). C# is the lovechild of C++ and Java, which is both awesome and sometimes frustrating. After over a decade of using C#, though, C# is my favorite language by far.
Lovechild of C++ and Java - good one!
Perhaps I will learn to love C# too, but the “size” the language is a learning impediment for me, especially for a non-engineer like me. More keywords, more ways to mess things up. Thanks again for all your work!
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.