www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Anti-OOP... stupid?

reply "Zero" <zero one.two> writes:
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?


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
Feb 14 2012
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
IMO, what would be stupid is that everything has to be object 
oriented.

You have problems where OOP is good, and other where it isn't. 
Use the tool that fit what you want to accomplish.

Screwdriver are great, but are useless when you are dealing with 
a nail.

On Tuesday, 14 February 2012 at 22:00:44 UTC, 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?


 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
Feb 14 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/14/2012 11:06 PM, deadalnix wrote:

 IMO, what would be stupid is that everything has to be object oriented.

 You have problems where OOP is good, and other where it isn't. Use the
 tool that fit what you want to accomplish.

 Screwdriver are great, but are useless when you are dealing with a nail.


Not exactly useless. Therefore it is hard to notice that they are not 
really fit for the job until having used a hammer. ;)
Feb 14 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 14, 2012 at 11:00:43PM +0100, 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?


I do that all the time. I guess that makes me crazy. :)


[...]

 What I want to know from you people... is that stupid? To even think
 about doing something like this? Basically mixing procedural and OOP?


D allows you to program in functional style, OOP, procedural style, or
any combination of them. There is a reason D was designed this way. :)



 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?


[...]

OOP has its own share of dangers and disadvantages. Which, sadly, most
people don't talk about very much because they don't have the guts to go
against the current cool trendy bandwagon that everyone's jumping on.

Templates, for one thing, don't fit very well into the OO paradigm (ever
tried a virtual template function?), even though you *can* use it to
enhance an OO-based design. And D's templates are one of the best things
about D, ever.

Of course, many aspects of OO does help with large projects, so it's
usually a good idea to take advantage of that. But that doesn't mean you
*have* to use OO, or that it's "bad" to mix in procedural stuff when it
suits you.

I mean, if you take OO to the extreme, that would require excluding all
those evil procedural constructs like if statements and for loops, and
write everything in terms of invoking object methods...  like this
monstrosity:

class MyClass {
	void myMethod() {
		IntVariable i;
		ForLoopFactory.create(
			new IntSetter(i.address(), new Number(0)),
			new BooleanCondition(
				new LessThanComparator(i.address(),
					100)),
			new IntAdder(&i, 1),
			new IfStatement(
				new EqualComparator(i.address(),
					new Number(42)),
				new FunctionCaller(writeln.address(),
					new String("Found it!")),
			)
		).execute();
	}
}

which is, of course, completely ridiculous.

The bottom line is, use whatever tools work best for what you need to
do. If OO works well, use it. If procedural code works well, that use
it. If both works well in different cases, then use a mix of both
depending on the circumstances.

Trying to shoehorn everything into an object is stupid.


T

-- 
Государство делает вид, что платит нам
зарплату, а мы делаем вид, что
работаем.
Feb 14 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
H. S. Teoh:


 I mean, if you take OO to the extreme, that would require excluding all
 those evil procedural constructs like if statements and for loops, and
 write everything in terms of invoking object methods...  like this
 monstrosity:
 
 class MyClass {
 	void myMethod() {
 		IntVariable i;
 		ForLoopFactory.create(
 			new IntSetter(i.address(), new Number(0)),
 			new BooleanCondition(
 				new LessThanComparator(i.address(),
 					100)),
 			new IntAdder(&i, 1),
 			new IfStatement(
 				new EqualComparator(i.address(),
 					new Number(42)),
 				new FunctionCaller(writeln.address(),
 					new String("Found it!")),
 			)
 		).execute();
 	}
 }
 
 which is, of course, completely ridiculous.


Smalltalk is a language composed of a very small number of parts, where every
thing is an object. So in a sense, you write code like that, with a better
syntax.

Bye,
bearophile
Feb 14 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 14, 2012 at 06:42:02PM -0500, bearophile wrote:

 H. S. Teoh:
 

 I mean, if you take OO to the extreme, that would require excluding all
 those evil procedural constructs like if statements and for loops, and
 write everything in terms of invoking object methods...  like this
 monstrosity:
 
 class MyClass {
 	void myMethod() {
 		IntVariable i;
 		ForLoopFactory.create(
 			new IntSetter(i.address(), new Number(0)),
 			new BooleanCondition(
 				new LessThanComparator(i.address(),
 					100)),
 			new IntAdder(&i, 1),
 			new IfStatement(
 				new EqualComparator(i.address(),
 					new Number(42)),
 				new FunctionCaller(writeln.address(),
 					new String("Found it!")),
 			)
 		).execute();
 	}
 }
 
 which is, of course, completely ridiculous.


 
 Smalltalk is a language composed of a very small number of parts,
 where every thing is an object. So in a sense, you write code like
 that, with a better syntax.


[...]

True, but that doesn't mean that it's evil to not program in Smalltalk.
:-)


T

-- 
Don't modify spaghetti code unless you can eat the consequences.
Feb 14 2012
prev sibling parent reply "foobar" <foo bar.com> writes:
On Tuesday, 14 February 2012 at 22:45:28 UTC, H. S. Teoh wrote:

 On Tue, Feb 14, 2012 at 11:00:43PM +0100, 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?


 I do that all the time. I guess that makes me crazy. :)


 [...]

 What I want to know from you people... is that stupid? To even 
 think
 about doing something like this? Basically mixing procedural 
 and OOP?


 D allows you to program in functional style, OOP, procedural 
 style, or
 any combination of them. There is a reason D was designed this 
 way. :)



 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?


 [...]

 OOP has its own share of dangers and disadvantages. Which, 
 sadly, most
 people don't talk about very much because they don't have the 
 guts to go
 against the current cool trendy bandwagon that everyone's 
 jumping on.

 Templates, for one thing, don't fit very well into the OO 
 paradigm (ever
 tried a virtual template function?), even though you *can* use 
 it to
 enhance an OO-based design. And D's templates are one of the 
 best things
 about D, ever.

 Of course, many aspects of OO does help with large projects, so 
 it's
 usually a good idea to take advantage of that. But that doesn't 
 mean you
 *have* to use OO, or that it's "bad" to mix in procedural stuff 
 when it
 suits you.

 I mean, if you take OO to the extreme, that would require 
 excluding all
 those evil procedural constructs like if statements and for 
 loops, and
 write everything in terms of invoking object methods...  like 
 this
 monstrosity:

 class MyClass {
 	void myMethod() {
 		IntVariable i;
 		ForLoopFactory.create(
 			new IntSetter(i.address(), new Number(0)),
 			new BooleanCondition(
 				new LessThanComparator(i.address(),
 					100)),
 			new IntAdder(&i, 1),
 			new IfStatement(
 				new EqualComparator(i.address(),
 					new Number(42)),
 				new FunctionCaller(writeln.address(),
 					new String("Found it!")),
 			)
 		).execute();
 	}
 }

 which is, of course, completely ridiculous.

 The bottom line is, use whatever tools work best for what you 
 need to
 do. If OO works well, use it. If procedural code works well, 
 that use
 it. If both works well in different cases, then use a mix of 
 both
 depending on the circumstances.

 Trying to shoehorn everything into an object is stupid.


 T


I agree with the general sentiment to have a large toolbox and 
using the right tool for the job be it functional, OOP, etc.. 
having said that, I have to strongly disagree with both claims 
above.

1. D templates are an enhanced version of C++ templates which are 
a poor design. The problem stems IMO not from issues with OOP but 
rather with the horrible idea of C++-like templates. Other 
languages have *much* better solutions which integrate better.

2. The above horrible example completely misrepresents OOP. The 
"correct" way to truly do control flow in OOP is a-la smalltalk:

class My class {
  void myMethod() {
      ...
      100.times({ ... }); // for-loop
      (myVar > 42).ifTrue({ ... }); // if statement
      (myVar < 100).if({.. code if true ...}, {... code if false 
...});  //  if statement with else clause
      ...
   }
}

etc.. incidentally, Smalltalk uses selectors (Objective-C is 
basically fugly smalltalk..) : (expression) ifTrue: [ ^42 ] 
ifFalse: [ ^24 ] the above returns 42 if true and 24 otherwise.
Feb 15 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
foobar:


 1. D templates are an enhanced version of C++ templates which are 
 a poor design. The problem stems IMO not from issues with OOP but 
 rather with the horrible idea of C++-like templates. Other 
 languages have *much* better solutions which integrate better.


C++ is one of the most commonly used languages, probably there are billions of
lines of C++ in use, and C++ library code uses templates often, so despite the
well known flaws of C++ templates (bloat, bad error messages, etc), they are
somehow "good enough", they aren't horrible.

Compared to C++, D templates introduce constraints, a better syntax, and more
uniform/sane semantics of details. Bjarne Stroustrup is still trying to invent
simplified Concepts to improve C++ templates, to give them "static" types.


polymorphism, Haskell type inference with type classes, Haskell template
extensions, are designed to satisfy different needs and constraints. All of
them are used and useful, none of them are perfect.

Bye,
bearophile
Feb 15 2012
parent "foobar" <foo bar.com> writes:
On Wednesday, 15 February 2012 at 15:35:37 UTC, bearophile wrote:

 foobar:


 1. D templates are an enhanced version of C++ templates which 
 are a poor design. The problem stems IMO not from issues with 
 OOP but rather with the horrible idea of C++-like templates. 
 Other languages have *much* better solutions which integrate 
 better.


 C++ is one of the most commonly used languages, probably there 
 are billions of lines of C++ in use, and C++ library code uses 
 templates often, so despite the well known flaws of C++ 
 templates (bloat, bad error messages, etc), they are somehow 
 "good enough", they aren't horrible.

 Compared to C++, D templates introduce constraints, a better 
 syntax, and more uniform/sane semantics of details. Bjarne 
 Stroustrup is still trying to invent simplified Concepts to 
 improve C++ templates, to give them "static" types.


 templates, ML polymorphism, Haskell type inference with type 
 classes, Haskell template extensions, are designed to satisfy 
 different needs and constraints. All of them are used and 
 useful, none of them are perfect.

 Bye,
 bearophile


I beg to differ. I was talking about the *design* aspect of 
templates and you seem to agree that it is flawed. the design 
*is* horrible and can be compared to other better designs. The 
fact that it is used in so much software is a completely 
orthogonal matter. Most people use qwerty keyboards (including 
me) but that does not mean it's the superior design. on the 
contrary, it was *intentionally* designed to be flawed for 
historical reasons that are no longer relevant. what is "good 
enough"? it is highly subjective. Is it enough to be commonly 
used by many people? what other criteria would be required to 
classify as good enough and not worth improvement? should we 
never strive to achieve better designs?

I don't know Haskell and won't comment on the above mentioned 

conflicts with OOP and are a good feature.
Feb 15 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/15/2012 03:30 PM, foobar wrote:

 ...
 1. D templates are an enhanced version of C++ templates which are a poor
 design. The problem stems IMO not from issues with OOP but rather with
 the horrible idea of C++-like templates. Other languages have *much*
 better solutions which integrate better.

 [snip.]


Please elaborate. What kind of construct in a language that supports OO 
solves the same set of problems D templates do and is unequivocally a 
better design?
Feb 15 2012
parent reply "foobar" <foo bar.com> writes:
On Wednesday, 15 February 2012 at 15:35:53 UTC, Timon Gehr wrote:

 On 02/15/2012 03:30 PM, foobar wrote:

 ...
 1. D templates are an enhanced version of C++ templates which 
 are a poor
 design. The problem stems IMO not from issues with OOP but 
 rather with
 the horrible idea of C++-like templates. Other languages have 
 *much*
 better solutions which integrate better.

 [snip.]


 Please elaborate. What kind of construct in a language that 
 supports OO solves the same set of problems D templates do and 
 is unequivocally a better design?


Lisp/scheme macros come to mind :) There are no issues AFAIK 
integrating those with OOP, in fact the OOP features are 
implemented with macros (CLOS).
Feb 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/15/2012 09:17 PM, foobar wrote:

 On Wednesday, 15 February 2012 at 15:35:53 UTC, Timon Gehr wrote:

 On 02/15/2012 03:30 PM, foobar wrote:

 ...
 1. D templates are an enhanced version of C++ templates which are a poor
 design. The problem stems IMO not from issues with OOP but rather with
 the horrible idea of C++-like templates. Other languages have *much*
 better solutions which integrate better.

 [snip.]


 Please elaborate. What kind of construct in a language that supports
 OO solves the same set of problems D templates do and is unequivocally
 a better design?


 Lisp/scheme macros come to mind :)


=D. I actually thought about explicitly excluding those to get a more 
meaningful answer. Using runtime code modification is cheating.

There are certainly ways to dynamically dispatch, expand and execute a 
macro in lisp. If every D program was allowed to include a complete D 
compiler, virtual template functions would work too. Can you point me to 
an implementation in lisp that does this and is actually fast enough to 
be considered for real work?


 There are no issues AFAIK integrating
 those with OOP, in fact the OOP features are implemented with macros
 (CLOS).


You can use templates to implement a multiple-dispatch virtual function 
system just fine. We are not talking about implementing OOP using 
templates, but about using templated virtual methods.

Anyway, I don't see your point yet: You seem to think templates are 
poorly designed because dynamic languages such as lisp are more flexible 
than static languages such as D?
Feb 15 2012
parent "foobar" <foo bar.com> writes:
On Wednesday, 15 February 2012 at 20:55:47 UTC, Timon Gehr wrote:
<snip>

 Lisp/scheme macros come to mind :)


 =D. I actually thought about explicitly excluding those to get 
 a more meaningful answer. Using runtime code modification is 
 cheating.

 There are certainly ways to dynamically dispatch, expand and 
 execute a macro in lisp. If every D program was allowed to 
 include a complete D compiler, virtual template functions would 
 work too. Can you point me to an implementation in lisp that 
 does this and is actually fast enough to be considered for real 
 work?


 There are no issues AFAIK integrating
 those with OOP, in fact the OOP features are implemented with 
 macros
 (CLOS).


 You can use templates to implement a multiple-dispatch virtual 
 function system just fine. We are not talking about 
 implementing OOP using templates, but about using templated 
 virtual methods.

 Anyway, I don't see your point yet: You seem to think templates 
 are poorly designed because dynamic languages such as lisp are 
 more flexible than static languages such as D?


I'm no lisp expert and as such Google would be better than me to 
point to specific implementations and such :)

regarding run-time modification of code - as I said, i'm no lisp 
expert but I did hear about lisp AOT compilers so it should be a 
matter of implementation. Another example which I'm more familiar 
with is Nemerle macros which are closely related to Lisp macros 
and follow similar design principles. In fact Nemerle macros are 
separately compiled plugins for the compiler which can manipulate 
the AST directly.

Regarding templated virtual methods - take a look at:
http://nemerle.org/wiki/index.php?title=Design_patterns
Feb 15 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/14/2012 11:00 PM, 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?


 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


I think that is not stupid at all.

Approaching the problem the way that feels most natural is likely a good 
idea. As long as you actively keep in mind code quality measures such as 
extensibility and maintainability, everything should work out nicely. I 
encourage you to use the right abstractions. If something should be a 
free-standing function, use a free-standing function. If it is hard to 
force the involved objects into a hierarchy, use templates instead of/in 
combination with sub-typing and inheritance. If you want to parameterize 
a function on a few actions, consider using closures. If it is really 
clear how a well-designed class hierarchy would look like, use OOP. etc.

The basic achievement of OOP is that it can be used to replace 
procedural code of this general form:

void foo(ref S x){
     switch(x.kind){
         case KIND1:
             ...
             break;
         case KIND2:
             ...
             break;
         ...
     }
}

void bar(ref S x){
     switch(x.kind){
         case KIND1:
             ...
             break;
         ...
     }
}

This pattern emerges very often in practise, that is why OOP is useful. 
If you have anything that should work like that, using classes will do 
the job. Whether or not you apply OOP, make sure to keep stuff 
extensible. It does not hurt at all if your code base is more flexible 
than necessary.
Feb 14 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote:

 [...]
 It does not hurt at all if your code base is more flexible than
 necessary.


[...]

This needs to be taken in moderation, though.

I've had to work with code that was unnecessarily flexible. (I.e.,
over-engineered.) So flexible, in fact, that almost none of us knew how
to use it, and the code ended up deteriorating into a morass of hacks
attempting to bypass an overly-general framework that nobody understood.

One particularly bad example was that part of the system had a whole
hierarchy of database-access classes, intended to replace having to
write SQL directly. The problem was that it was so poorly documented,
and so difficult to understand, not to mention requiring a instantiating
a whole bunch of objects just to do something as simple as "SELECT *
FROM some_table;", that eventually people just resorted to writing a
function for executing SQL directly, thus bypassing the entire
over-engineered mess.

And that was only a small part of it. There were other beautifully
designed, fully OO, and fully generic classes, that accomplished
everything from the most trivial of tasks to the most advanced
high-level abstractions. Like the IPC mechanism, for which at one point
I had to write code to get through *six* layers of abstraction just to
call a single function. One layer of which involved fwrite(), fork(),
exec(), and fread(). Such was the result of the original code base being
much too flexible than it needed to be.


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson
Feb 14 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/15/2012 12:12 AM, H. S. Teoh wrote:

 On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote:

 [...]
 It does not hurt at all if your code base is more flexible than
 necessary.


 [...]

 This needs to be taken in moderation, though.

 I've had to work with code that was unnecessarily flexible. (I.e.,
 over-engineered.) So flexible, in fact, that almost none of us knew how
 to use it, and the code ended up deteriorating into a morass of hacks
 attempting to bypass an overly-general framework that nobody understood.

 One particularly bad example was that part of the system had a whole
 hierarchy of database-access classes, intended to replace having to
 write SQL directly. The problem was that it was so poorly documented,
 and so difficult to understand, not to mention requiring a instantiating
 a whole bunch of objects just to do something as simple as "SELECT *
 FROM some_table;", that eventually people just resorted to writing a
 function for executing SQL directly, thus bypassing the entire
 over-engineered mess.


Directly executing SQL is a much more flexible approach ;).


 And that was only a small part of it. There were other beautifully
 designed, fully OO, and fully generic classes, that accomplished
 everything from the most trivial of tasks to the most advanced
 high-level abstractions. Like the IPC mechanism, for which at one point
 I had to write code to get through *six* layers of abstraction just to
 call a single function. One layer of which involved fwrite(), fork(),
 exec(), and fread(). Such was the result of the original code base being
 much too flexible than it needed to be.


 T


For what I am concerned, flexible means *simple* to adapt, not that the 
existing code is so bloated and general that it does not need to be 
changed in order to implement a new functionality. In fact, I'd argue 
that such a design is inflexible: All new code is assumed to follow the 
bounds of the legacy code base.
Feb 14 2012
prev sibling parent James Miller <james aatch.net> writes:
On 15 February 2012 12:12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote:

 [...]
 It does not hurt at all if your code base is more flexible than
 necessary.


 [...]

 This needs to be taken in moderation, though.

 I've had to work with code that was unnecessarily flexible. (I.e.,
 over-engineered.) So flexible, in fact, that almost none of us knew how
 to use it, and the code ended up deteriorating into a morass of hacks
 attempting to bypass an overly-general framework that nobody understood.

 One particularly bad example was that part of the system had a whole
 hierarchy of database-access classes, intended to replace having to
 write SQL directly. The problem was that it was so poorly documented,
 and so difficult to understand, not to mention requiring a instantiating
 a whole bunch of objects just to do something as simple as "SELECT *
 FROM some_table;", that eventually people just resorted to writing a
 function for executing SQL directly, thus bypassing the entire
 over-engineered mess.

 And that was only a small part of it. There were other beautifully
 designed, fully OO, and fully generic classes, that accomplished
 everything from the most trivial of tasks to the most advanced
 high-level abstractions. Like the IPC mechanism, for which at one point
 I had to write code to get through *six* layers of abstraction just to
 call a single function. One layer of which involved fwrite(), fork(),
 exec(), and fread(). Such was the result of the original code base being
 much too flexible than it needed to be.


 T

 --
 Why are you blatanly misspelling "blatant"? -- Branden Robinson


Basically, flexibility is good, but you have to make sure you are
actually writing a program, not a platform or framework, or worse a
COBOL. (COBOL being COmmon Business-Oriented Language, intended for
"business people" to use, and let programmers get back to writing
device drivers <.<)
Feb 14 2012
prev sibling parent Vijay Nayar <vnayar wgen.net> writes:
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?


 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
Feb 15 2012