Many reasons why non-OOP methodology creates problems come from how
scoping works in a language. In C, there's one global name-space, so
declaring functions anywhere can lead to major problems: unexpected
dependencies, unclear sequence of execution, aberrant mutations, name-space
conflicts, etc.
However in D, much like Python, true modules are supported by the
language. There is no "global" scope the programmer has access to, only
the module scope which matches file scope. This solves the name-space
problem.
Other than that, make sure your module level functions and values only
depend on other modules in a predictable fashion, do only a small set of
mostly self-contained things, and are well documented.
Also remember that module-level variables have thread scope, so by
default, each thread will have its own copy.
- Vijay
On Tue, 14 Feb 2012, Zero wrote:
Hello!
I've recently started to work with D, and I'll start a "bigger" project soon,
using it. For a few days I've been thinking about the approach I'll take
here, and since I don't /have/ to use full OOP in D, I was wondering... how
crazy is it to not use full OP nowadays?
Naturally one would use objects, but since this isn't C#, or Java, not
freaking everything has to be an object. The C style kinda feels more natural
to me. (I know, I know, C naturally can do some OOP like stuff, etc... but
you get the idea, mainly normal functions, some globals, yada, yada.)
What I want to know from you people... is that stupid? To even think about
doing something like this? Basically mixing procedural and OOP? I know about
the dangers, and disadvantages, but if those don't scare one away, would you
consider it bad, if someone did this, on a larger project?
I'm looking forward to your answers.
Zero
