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.
