On Monday, 3 March 2014 at 18:46:24 UTC, Chris wrote:
On Monday, 3 March 2014 at 18:03:12 UTC, Frustrated wrote:
On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote:
On Sunday, 2 March 2014 at 10:05:05 UTC, Dicebot wrote:
There is nothing wrong about not using templates. Almost any
compile-time design can be moved to run-time and expressed
in more common OOP form. And using tool you have mastery of
is usually more beneficial in practice than following the
hype.
Yes DB, we can soldier on happily, but it would not do any
harm to understand templates.
The documentation examples quickly make your eyes glaze over,
looking at the code in Phobos is doubtless instructive, but
you can wade through a lot of that without finding what you
want. Also I discovered an interesting fact today. the word
'mixin' does not appear in the language reference Templates
section of dlang.org.
It should be used in at least one example. I just discovered
by trial and error that I could use 'mixin' in Templates (as
opposed to Template Mixins), and when you know that it seems
likely that you can accomplish lots of stuff you couldn't
before.
While I'm here, has anyone discovered a way to fudge a
constructor super(..) call in a mixin template that's
included in a class constructor. Since the mixin template is
evaluated in the scope of the constructor, it seems like it
should be OK.
I'm sure I'll get there in time ;=)
Steve
You've got to learn to think a bit more abstractly. Templates
are generalizations of things.
I think the problem is not that people don't understand
templates in the sense that they are abstractions. The question
is whether there are loads and loads of use cases for them.
It is irrelevant if there are loads and loads of use cases for
them. Just because people don't use something doesn't mean it is
useless.
Suppose I want to add two numbers using a function.
int add(int, int)?
double add(double, int)?
float add(float, int)?
char add(char, double)?
etc....
which one? Do you want to have to create a function every time
for every time?
This is a typical use case and always mentioned in tutorials.
The question is how many of these "typical" cases one
encounters while writing software.
Look at the STL library if you do't believe templates are
useful...
I think another problem with templates is that it is not always
clear what is abstracted. The type or the logic? Both? In the
above example the logic remains the same and is reproduced by
the compiler for each type. Sometimes the logic can be
abstracted for which type independence is important. But I'm
not sure if that can be called a template in the purest sense.
E.g. an algorithm that finds the first instance of something
might be different for each type (string, char, int) and the
"abstract" implementation has to differentiate internally (if
string > else if int > else if ...). But this is no longer a
template, or is it?
Both logic and types are abtracted. Even though the template
might use the same operator, the compiler must determine which
concrete operator to use.
The addition between the two abstract objects also requires an
abstract operator.
The great thing is, because the abstract logic is
identical("adding two things") makes the template actually
useful. If it wasn't we would have to specialize the template for
all the different possible binary combinations and then it would
defeat the simplification that abstract is suppose to offer.
The the logical process is used when one looks at procedural code
and realizes that one can "simplify" it by using oop.
Templates give you the same power over oop that oop gives over
non-oop. But just because templates[oop] are available doesn't
mean you have to use it or it is always the best solution.
I use templates all the time. I create them to simplify some task
then put them in a library. For me, templates allow me to
streamline things that I couldn't otherwise do. Any time I feel
like something is being repeated a lot I automatically think that
a templates will help. I hate "copying and pasting" and so I tend
to use templates a lot.
One of the main uses of templates is compile time type safety.
This is necessary with oop because oop allows one to create types
at compile time. Hence, the need to be able to make your oop
"safe" is a natural step and templates help you accomplish that.
e.g., Array's of objects vs Array's of a Type. One is much safer,
informs the about what your intentions are so it can make better
informed decisions.
e.g., Array!Type allows the Array to determine if the Type
supports certain things at **compile time**. Array!Object can't
do this at compile time.
If you can't see the benefit of Array!Type vs Array!Object then
you are beyond help. (this is not to say Array!Object is always
useless, but it is the most generic you can get and the compiler
can do little to help the situation)
I'll give you a simple example: One could create an Array type
that allows one to traverse the array in a multitude of ways.
Suppose the objects stored by the arrays are arrays themselves.
If the Array is templated it could easily figure this out and
create an iterator that iterates over the sub-array(calling its
iterator).
This way one could easily display a flat list of the array [of
arrays [of arrays ...]]. Because the Array type could figure out
all this at compile time it would be way more efficient than
having to use run-time reflection to determine of the object is
an array and if it has the iterator. (it would also be easier to
code)
Basically you have the choice:
------------ <- "template" way of thinking (more general than oop)
-------- <- Oop way of thinking (more general than procedural)
----- <- procedural way of thinking... "Old School"
- <- Punch Cards
(it's not quite that simple as templates or more of an offshoot
of oop)
If you are thinking at the template level then you will know when
to use templates. If you are thinking at the oop level, you
always go for your oop hammer(duh, cause everything looks like an
oop nail). If you are thinking at the procedural level then you
always try to solve problems in the procedural way.
I prefer the top-down approach... Call me a racist but I just
hate punch cards.
