No, I wasn't talking about just chunks of code you can call from anywhere and act like a singleton, and I am aware of static classes. Modules could contain a static class, but they're much, much more than that. They can be as little as a few procedural functions or they can contain a few hundred classes. They can contain BlitzMax code, C Code, C++ code or a combination of all of the above. They have their own namespace too. They're much more akin to a class library.
Ahh.. ok.
Unlike java, C# doesn't require you to have one class/namespace per file, so you could at least put multiple unrelated C# namespaces/classes/methods, in one monolithic file.
There are plenty of good reasons why you shouldn't do that (whether it's homogenius C# code or a mixture of a bunch of other languages), but that's more of a coding standards/best practice debate.
Sure, but as as I already said, I just don't like class modules. I find it messy having DLL's all over the place, and there's no forced structure about them. I can put the source to a class module anywhere I like, and I'm lazy, so I probably will. When I come to back up all my class modules, where are they? All over the hard drive, of course, because I'm just that disorganized.
I agree. It's messy to have dll's all over the place. But then, there's really no reason for it. And there's really no getting around class modules in any OO language (or OO-ish language), including Blitz. So you're going to be miserable for your remaining days as a programmer, or you'll learn to embrace it :)
Heck, the .Net Math module is a class library. It just happens to reside in the GAC (which I suppose is an option for your own modules as well)
You also don't have to reference DLLs. Studio also lets you reference other projects, and will use relative paths when possible to find them.
If you must reference DLLs, make a "libraries" folder outside of your project and reference them.
Studio doesn't have any real "enforced" organization standards, but there are some implied ones mostly borrowed from Java. For instance, folders in a project represent a subdivision of a name-space, and when you add a class under that folder, it will append the folder name to the generated name space of that file.
By default and when VS interacts with source control programs, it tends to want you to organize your code folder stucture in a Solution->Project->Namespace->file(s) fashion.
I personally don't agree that solution folder should be the root of all it's referenced project files (what if you want to share those projects in a different solution?), so I usually end up re-organizing and re-pointing my solution files (which is not always a very pleasant experience).
I guess the point here is to make a structure you're comfortable with that doesn't bend the rules too much and be consistent about it. You might end up fighting the system on a few things, but you will eventually bend it to your will.
I know how it's done, I just don't think it's as elegant as it is with BlitzMax. Again, this may be because BlitzMax has modules and you can encompass all your external code in one of those.
Elegant is apparently subjective.
Typically in an OO design, you keep all calls (external or not) in the class in which it's relevant. Having one big monolithic file to handle things like violates this principle and creates artificial dependencies that could potentially bite you later.
But again, that's another organizational debate. A good chunk of OO design is understanding how to effectively organize your class and service layers so that they are well focussed and their functionality scope doesn't creep outside of their purposes.
I can guarantee you that no such effort will ever be made. It is a good idea for cooperation with a major company, and thus contrary to the very character of BRL.
Unfortunately, I'd agree with you here. I've said this a number of times in the past: BMax should be targetting "abstract" JIT compilers and emitting java byte-code and/or .Net assemblies, rather than compiling straight to native code (though that would be a nice 3rd option to make everyone happy). Abstract compilers are not going away, and I'd wager that this is where the future of software development of 4GL's will continue to ground themselves in. Even Delphi recently bit the bullet and now targets .Net.
Scalability across multiple competing O.S's (as well as moving from 32 to 64 bit processors) will further strengthen the position. Imagine how quickly operating systems could evolve if backward compatibility issues for software were resolved simply by writing a compiler that resides at the operating system level.
Also, the burden of the compiler itself and it's optimizations wouldn't be on BRL. Imagine the amount of time that would free up to do other things...
I know many disagree with me on this point, but XNA portability is just one of the scenarios that would be a step closer to possible under that situation. I know some also would disagree with the focus not being on compatibility with older machines (which is what targetting non-native code somewhat implies). To that, I'd say the future lies in the future, not the past.
There is currently no language that abstracts above those two targets (java and .Net). I'd say any language that can pull that off and generate binaries that target both of those platforms will gain a LOT of attention in the entire development community (not just the game development community)