[bolts] bolts.functioneditor - module for building function mixins?

[aliak]

On Tuesday, 7 April 2020 at 16:58:12 UTC, Jean-Louis Leroy wrote:
[...]
>
> I haven't given a lot of thought to using this approach beyond 
> functions. Probably manipulating enums and classes are less of 
> a pain (no parameter storage classes), and may need much fewer 
> string mixins.

Yeah, I actually forgot the use case I was trying to make it for. 
So I agree at this time.

>
> However, I do like the idea of composing e.g. enums using a 
> meta-objects, like:
>
>   
> mixin(EnumEditor!"Fruit".addEnumerator!"Grapefruit".etc.etc.asString);
>
> On a side note, I would like to have a very simple construct 
> that turns an identifier into a string (see 
> https://forum.dlang.org/post/ayzrsajzcelavxdbwbji@forum.dlang.org).

Turn an identifier into a string?

int myint;
assert(__traits(identifier, myint) == "myint");

Like that?

The forum post made me think of something more like:

assert(isThisAValidIdentifier!("some string"))

?

>
> Finally I am not set on the template and module names. 
> `FunctionEditor` is a bit errr flat. Transmogrify sounds much 
> better ;-)

Hehe yeah, the name came from the Calvin and Hobbes comic books 
(https://calvinandhobbes.fandom.com/wiki/Transmogrifier)

But aaaaanyway, ok so thanks for the explanations :)

This is very cool stuff. I'm not exactly sure how the entire 
system can be seen yet - lots of questions , but if could build a 
static reflection system that is easy to use and allows for the 
mutation of compile time entities in order for derived entities 
to be mixed in, that "sounds" very cool.

I'm thinking use-cases can slowly be built up one by one, but the 
initial use-case you have is a great starting point. So, yeah, 
I'm all for it.

I opened a branch: 
https://github.com/aliak00/bolts/tree/reflection

And I put up an initial commit for variable reflection: 
https://github.com/aliak00/bolts/commit/5da534466285ae7357b56ccf9d60470a63d2ac61

At this time I have no idea how well that will work in the 
general sense but time will tell. It would be great if you could 
push small pieces of the function editor in to there (make a new 
file under the reflection module and just start with that?).

The entity traits should be integrated with the existing traits 
as well so that the source of truth remains the same - I find 
that's the hardest part about this library - there're so many 
ways to do things and it's already hard to keep track of which 
method is used where (even with a library as small as it is right 
now)