Mixed up over mixins.

[Johnson via Digitalmars-d-learn]

On Monday, 21 August 2017 at 07:34:23 UTC, WhatMeForget wrote:
> On Sunday, 20 August 2017 at 22:50:40 UTC, Johnson Jones wrote:
>> On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:
>>> [...]
>>
>>
>> It's not difficult, it's just new. It's not that you are a 
>> poor programmer, but you simply have not learned how to think 
>> about mixins correctly. Stop whining about it and focus that 
>> energy on working with them.
>>
>> [...]
>
> Thank you.  You have rejuvenated my quest for mixin mastery :)

Just stick with it ;) Things will click. The more you trudge 
through them and just try to immerse yourself in it the faster it 
will happen. I use mixins all the time because they are a great 
way to simplify code... although actually writing them can be a 
pain because you can't debug them in any sane way.

Remember, that you will generally use string generation a ton 
because that is mainly what you are working.

Sometimes, for complex tasks I might have to write a function 
that I run at runtime like a normal program that takes in a 
string and outputs it. This lets me debug properly. As long as 
one doesn't use crazy io(even file IO is blocked ;/) the same 
function can be run at compile time(CTFE).

This means

myfoo("asdfasdf");

will be ran at compile time, the reason is simply that the input 
is constant, there are no side effects, and so the output can be 
computed at compile time.

But the same function can be debugged if ran at runtime... and 
remember, the output is a string, so you can just print it out, 
no mixin is occuring at this point.

The idea is that you make sure the string output is going to be 
the correct D code you want to mixin. It should look like normal 
D code, because if you do a mixin on it, it has to be to compile. 
Any syntax errors will be picked up and you'll be hunting them 
down because D will give you an obtuse error rather than a 
specific line number in the mixin(this is a severe issue with D 
but no one seem to care). If you debugged at runtime, you will 
get a line number where the error occurred, which is why you go 
that route.


Once you've gotten your function written to do the code, you 
simply wrap a mixin() around it, you might have to change a bit 
of runtime to compile time stuff(file io to import) and then all 
that string stuff that you generated becomes D code!

mixin("int i = 3"); <- bug
mixin("int i = 3;"); <- ok

same as

int i = 3;

useless example but sometimes it's helpful. Sometimes to get the 
things working you have to use mixins of mixins:

mixin("mixin("~something~");");

or, take this example

auto alpha = "hello";
mixin("w"~"r"~"i"~"te(`"~alpha~"`);");

before the mixin we have

"w"~"r"~"i"~"te(`"~alpha~"`);"

which, when simplified is

"write(`"~alpha~"`);"

which, since alpha is a constant, we have

"write(`hello`);"

which, the mixin simply does

write(`hello`);

which is now D code.

A mixin, in a sense, just "unstringifies" it's argument and 
inserts it directly in to the source code... it better be valid 
code, which also means the string better be a valid string of D 
code.