On Saturday, 1 March 2014 at 18:00:21 UTC, Steve Teale wrote:
> On Friday, 28 February 2014 at 19:06:26 UTC, Dicebot wrote:
>> On Friday, 28 February 2014 at 18:42:57 UTC, Steve Teale wrote:
>>> Is this typical - libraries use templates, applications don't, or
>>> am I just being unimaginative?
>>>
>>> Steve
>>
>
>> Also every time you catch yourself doing any sort of copy-paste, it is quite possible that it can be replaced by mixin / template mixin instead. Application that are built in more declarative way benefit more from such tool set than traditional imperative ones.
>
> In have a couple of case that always require me to find some other instance of it, and then copy/paste, But then I need to edit the pasted code anyway because in any particular case it needs to deal with different command info, so how can mixins help me? I have already dealt with the yada-yada cases by old-fashioned OOP.
>
> From the various answers to this question I have concluded that I should not worry about it. If there's a need for a template I think I am already recognizing it.
>
> Thanks!all()
> Steve

This is the best think I've read:

https://github.com/PhilippeSigaud/D-templates-tutorial

On Sunday, 2 March 2014 at 15:23:03 UTC, H. S. Teoh wrote:
> This is a pretty good primer to templates:
>
> 	https://semitwist.com/articles/article/view/template-primer-in-d
>
>
>
The trouble is with most of these tutorials that they offer examples that are things you would probably never want to do. I can already add an int to an int, or a double to a double, or an int to a double.

Perhaps the examples should pick on something like vector operations, but then who would be doing those with int, or some class? It would be doubles or pairs of, as in struct Coord.

I believe readers would study documentation and examples much more carefully if they were things they might realistically want to do. And that won't be type conversion - std.conv already does a pretty good job on that. So what?

We could really do with a place where template savvy open source contributors could publish interesting examples of template use.

Otherwise, Joe Soap, like me, can spend a great deal of time and effort in:

a) Determining when the use of a template might be advantageous,
b) Hacking at test programs to determine what the documentation means, and what works, and what doesn't.
c) After that, deciding whether it would be just as effective to use two or three separate methods.

Steve


Steve

On Sunday, 2 March 2014 at 18:59:23 UTC, Steve Teale wrote:
> On Sunday, 2 March 2014 at 15:23:03 UTC, H. S. Teoh wrote:
>> This is a pretty good primer to templates:
>>
>> 	https://semitwist.com/articles/article/view/template-primer-in-d
>>
>>
>>
> The trouble is with most of these tutorials that they offer examples that are things you would probably never want to do. I can already add an int to an int, or a double to a double, or an int to a double.
>
> Perhaps the examples should pick on something like vector operations, but then who would be doing those with int, or some class? It would be doubles or pairs of, as in struct Coord.
>
> I believe readers would study documentation and examples much more carefully if they were things they might realistically want to do. And that won't be type conversion - std.conv already does a pretty good job on that. So what?
>
> We could really do with a place where template savvy open source contributors could publish interesting examples of template use.
>
> Otherwise, Joe Soap, like me, can spend a great deal of time and effort in:
>
> a) Determining when the use of a template might be advantageous,
> b) Hacking at test programs to determine what the documentation means, and what works, and what doesn't.
> c) After that, deciding whether it would be just as effective to use two or three separate methods.
>
> Steve
>
>
> Steve

I'm always willing to use templates, but maybe in fact the use cases are limited. I have a class for html elements (that implements DOM functionality), and a class for building trees with the tags. Of course, for html tags only string as a type makes sense.

class Element(T) {

}

or

class HTMLElement(T) if (is (T == string)) {

}

Tree(T) {

}

I implemented it as a template, because I thought it might be useful for other types as well, if I want to build a hierarchical tree of extracted data, be it integers, floating point numbers or whatever at a later point. However, I don't know a) if this will ever be the case and b) if I won't have to modify the template to adapt to new data types (which kinda defeats the purpose). I'm not against templates, I'm just not sure, if there are so many general or generalizable cases in programming for which templates are  _the_ solution.

On Monday, 3 March 2014 at 16:40:09 UTC, Chris wrote:
> I'm always willing to use templates, but maybe in fact the use cases are limited. I have a class for html elements (that implements DOM functionality), and a class for building trees with the tags. Of course, for html tags only string as a type makes sense.
Really?
Did you consider that there are three different flavors of "string"?
Does your function really only deal with string?
Or would someone need wstring or dstring?

> class HTMLElement(T) if (is (T == string)) {
>
> }
>
> [...] I don't know [...] if I won't have to modify the template to adapt to new data types (which kinda defeats the purpose).
Not much if the different types have common features.
Most times it is still a big save of code to implement, even
if the types need to be handled different in some places.

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.

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?

Whats the only significant difference between all of them? If you can't answer this then you can't abstract and which is the reason you don't understand templates.


I could use one template function to handle all those cases above. That's what makes it powerful. I can basically write one function when you have to write 8, 10, 20 or whatever.

S add(S, T)(S a, T b) { return cast(S)(a + b); }

The compiler then generates all the concrete use cases for me. (and using oop can make it more powerful, S and T could be vectors) As long as the first type has an binary addition operator on it that takes the second type it will work and the template will work without change.

But you want to continue using the hold way. It is analogous to those that want to continue to write procedural code because they don't see the what oop has to offer.

BTW, how did you learn oop? Did you understand it all perfectly by reading a book or did you learn best by writing code that used it?

If you don't attempt to use templates, even in example code, you won't get it.

On Monday, 3 March 2014 at 18:03:12 UTC, Frustrated wrote:
>
> If you don't attempt to use templates, even in example code, you won't get it.

What I don't get in this discussion is that all those fine phobos examples are neglected. Yes, it is library code, but writef/formattedWrite/std.conv.to, std.container, std.range, std.algorithm are only possible with meta-programming and are fine examples of the usefulness of templates.

This thread looks like this to me: I bought a new hammer, but not everything is a nail. Give me back my money!

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.

> 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.

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?

[snip]

On Monday, 3 March 2014 at 17:24:08 UTC, Dominikus Dittes Scherkl wrote:
> On Monday, 3 March 2014 at 16:40:09 UTC, Chris wrote:
>> I'm always willing to use templates, but maybe in fact the use cases are limited. I have a class for html elements (that implements DOM functionality), and a class for building trees with the tags. Of course, for html tags only string as a type makes sense.
> Really?
> Did you consider that there are three different flavors of "string"?
> Does your function really only deal with string?
> Or would someone need wstring or dstring?

Good point. Of course! I was thinking in an abstract way of "string".

>> class HTMLElement(T) if (is (T == string))
>>
>> }
>>
>> [...] I don't know [...] if I won't have to modify the template to adapt to new data types (which kinda defeats the purpose).
> Not much if the different types have common features.
> Most times it is still a big save of code to implement, even
> if the types need to be handled different in some places.

But it's no longer a template then, is it?

On Monday, 3 March 2014 at 18:46:24 UTC, Chris wrote:
> 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?

What makes you think so? Template with specializations is still a template.

On Monday, 3 March 2014 at 19:32:51 UTC, Dicebot wrote:
> On Monday, 3 March 2014 at 18:46:24 UTC, Chris wrote:
>> 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?
>
> What makes you think so? Template with specializations is still a template.

Maybe I'm a bit too philosophical about this. But consider the following (made up) case:

struct MyTemp(T) {
    // ...
    T add(T a, T b) {
        if (a is string && b is string) {
              return a~b;  // or return a~"+"~b; or whatever
        } else if (a is integer && a is integer) {
              return a+b;
        }
    }
}

I don't know if this can be considered a "pure" template. It is a template of sorts, but the type specialization in the function add makes it a watered-down template, imo. You could have a version of MyTemp that handles only strings (and dchars, wchars) and one that handles only numbers. But this you also have in OO where this is achieved by inheritance and interfaces.

I think the confusion about templates often arises from the fact that it is mainly about types, i.e. that the compiler fills in the template with the appropriate type. But it is not an abstraction of the logic behind a function. The logic in a+b is the same for

int + int; float + float; float + int ... and thus not an abstraction of adding one thing to another.

It is different for string + string. Of course, we can have separate templates, one for numbers, one for strings, one for arrays etc. But then it is less general. I am not against templates, far from it, I like them, and std.algorithm is a brilliant example of how useful they are. However, I wonder to what extent they can be useful when writing a specialized program as opposed to a general library. Walter mentioned that he uses them a lot these days. How? I want to learn.