On Fri, Dec 21, 2018 at 09:26:28PM +0000, Dennis via Digitalmars-d-learn wrote: > The most fundamental problem that these features tackle is that code > is costly, so making code-bases smaller and more reusable saves effort > spent on maintaining large code-bases and rewriting code to suit a > different situation.
I disagree that OO is the best thing since sliced bread. It's useful for certain kinds of problems, but shoehorning everything and the kitchen sink into OO just creates smelly anti-patterns, like singleton classes and needless extra layers of indirection when your problem domain doesn't actually *need* full-out runtime polymorphism. Templates and mixins in D offer a different kind of tool for the job: compile-time polymorphism and meta-programming (esp. code generation). The bottom line is that not only code is costly, but that boilerplate code violates the DRY principle and often leads to bugs that are fixed in one place but not in others because the person making the fix can't possibly know about all the different places where the boilerplate was copy-n-pasted. Templates and mixins let you abstract away needless boilerplate so that you (almost) never have to repeat yourself, and if you later discover a bug in your boilerplate, fixing in one place (i.e., the template) fixes all instances of it, rather than having to chase down the (n-1) other places where the same bug appears. Templates also allow you to abstract the algorithm away from the data it operates on (contrary to OO, where the algorithm is tightly bound to the data, and you're up the creek without a paddle if you want to apply the same algorithm to a different type that the author didn't think of). Instead of forcing your clients to conform to the types that you specify, templates let you write code that adapts itself to a user-given type instead, producing a customized instance that works best with that type with no runtime overhead (because all of this is done at compile-time). Mixins let you generate arbitrary code in response to user-given parameters. It's extremely powerful, though rarely needed. But when necessary, it can let you factorize your code in powerful ways that would otherwise be impossible. A simple example is operator overloading in user-defined arithmetic types, where mixins let you consolidate all the boilerplate of performing some given arithmetic operation `op` on one or two arguments. More advanced examples include code generation from DSLs, that let you process arbitrarily complex strings at compile-time to generate D code for it, e.g., take in a grammar specification and generate parser code optimized for the specifics of your grammar (cf. Pegged). As opposed to writing the parser code yourself (extremely tedious, error-prone, and time-consuming), or using a runtime parser engine (slow because of runtime overhead). // It doesn't mean OO is useless in D, it just means that OO is just another tool for the job, and while it may work really well for certain kinds of programming problems, some other kinds of problems are better solved with other tools. The right tool should be used for the right job; you shouldn't have to contort your problem domain in unnatural ways just so you can say "hooray my code is OO, I'm on the OO bandwagon yay". T -- The problem with the world is that everybody else is stupid.
