Some Fundamental Paradigm Questions

[Dennis]

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.

On Friday, 21 December 2018 at 12:39:48 UTC, Ron Tarrant wrote:
> 1) What problem does mixins solve?

- Lots of code is redundant
...and not in an error recovering way but in a "if you don't keep 
the boilerplate in sync things will break down" kind of way. For 
example, Java IDEs can create constructors, equals, and toString 
methods based on fields, but you better not forget to update 
these when you add a field. A mixin template for these reduces 
code size and errors.

- Interfacing with other code is annoying
Mixin allows you to abstract that away cleanly. You can write D 
code in your own way and let a mixin template do the binding for 
you. For example, when making a VST (audio effect / instrument 
plugin) in dplug:
https://github.com/AuburnSounds/Dplug/blob/master/examples/simple-mono-synth/simplemonosynth.d#L12
Or when writing D functions that can be called from Excel:
https://youtu.be/xJy6ifCekCE?t=3m49s
(The link goes to the mixin part directly but I recommend 
watching the whole video)

- Some things are not easily expressed imperatively
...so you may want to use domain specific languages. For example, 
Pegged allows you to describe a language grammar, and parser code 
can be mixed in automatically.
https://github.com/PhilippeSigaud/Pegged

> 2) Under what circumstances would I use mixins?
Whenever you want to create boilerplate automatically or factor 
out repeated code. The disadvantage is that code becomes harder 
to reason about and debug because of the extra indirection. If 
something can be solved with other features you should generally 
prefer that over mixins.

> 3) What problem does a template solve?

- Code duplication
In Java you have generic List / HashMap containers using 
Generics. D's templates accomplish the same, but not only can you 
make a type generic, you can also pass values or aliases as 
template arguments.

- Code often isn't reusable because it makes assumptions about 
the implementation
Apart from templates allowing substitutions of generic names with 
types and values, they can also inspect those and change behavior 
accordingly. Take for example design by introspection:
https://youtu.be/29h6jGtZD-U?t=30m54s
(the timestamp leads to a bit comparing it with libraries that 
are either larger in code size or less flexible)

What should your checked int do on overflow: Saturate, abort, 
throw an Exception? Just put it in templates and the library user 
can decide and won't have to choose a different library because 
they happen to be in a nothrow environment and the library uses 
exceptions.

> 4) When would I use a template?

Whenever you don't want to assume a specific type, value or 
behavior, make a template and put the varying parts behind 
template parameters.

> 5) Are either mixins, templates, or both intended to make OOP 
> code easier to read, more reliable, or in some other way 
> improve the OOP coding experience?
>
> 6) Or, are mixins and templates completely different paradigms 
> intended to solve problems in ways OOP can't?

Mixins are great for adding generic methods like constructors, 
toString, toHash, equals methods. They can also be used to avoid 
OOP: instead of inheriting features, you can mix them in.

I think OOP allows very flexible designs _as long as you're in 
Object land_. Bringing back Java (I don't know PHP very well 
sorry): An ArrayList of integers can't use the primitive type 
int, it has to be a list of Integer objects with some language 
hacks that allow you to use Integer and int interchangably most 
of the time. In D, an ArrayList!int would actually generate code 
that handles on primitive int types. (though in D, you would 
probably use an int[] instead ;) )

So in a way, templates and mixins are a way to bring the 
flexibility of OOP outside of Objects so primitive types can also 
benefit from it, resulting in faster and simpler code. But they 
can also be used to further improve your OOP designs, it's up to 
you.

> 7) Is there a comprehensive stash/repository of GoF patterns 
> implemented in D?

I don't know about one, but I think most design patterns in Java 
can easily be translated to D. When I translated Java to D, 
substitutions like ClassName() -> this(), extends -> :, and 
boolean -> bool got me 90% there. However, solving the problems 
that design patterns address can be done with language features.
Instead of the Strategy pattern you can pass function pointers / 
delegates in D.