Upcoming refraction module in bolts [was: DUB project type support for Emacs Projectile]

[Jean-Louis Leroy]

On Monday, 15 June 2020 at 16:03:08 UTC, jmh530 wrote:
> On Monday, 15 June 2020 at 13:17:11 UTC, Jean-Louis Leroy wrote:
>> [snip]
>>
>> Nah, I saw it. Well. My take on it has been ready for months 
>> but I had to wait for my employer's permission to publish it. 
>> They are very open-source friendly, and as a consequence there 
>> is a glut of requests for open-sourcing personal projects. I 
>> guess I am going to cancel my request...
>>
>
> Ah. I suppose that depends implementation/performance/feature 
> differences...

No, it's just that they are essentially equivalent. I spent some 
time supporting InterfaceValues to immutable and const classes 
and objects. Not sure if he has that, I haven't played with tardy 
yet. OTOH I didn't bother with allocator support.

>
>> On the bright side, I just got authorized to contribute my 
>> work on function refraction (currently part of openmethods) to 
>> bolts. You can see it here: 
>> https://github.com/aliak00/bolts/pull/10
>
> I saw when you mentioned it earlier. Though it hasn't been 
> something I've needed as yet, it's good to know that it's there.
>
> This allows the function mixins to work when they are in 
> different modules, right? I don't see a test for that, but it 
> might be useful to include such an example (I'm pretty sure

You mean an example with two modules?

I plan to write a D blog entry that walks through the pitfalls of 
cross-module mixing.

> Atila's tardy makes use of a similar functionality when they 
> are in different modules).

Actually we were in contact (and with Ali of course). I pointed 
him to the part of openmethods that creates functions. He has a 
'refraction.d' too. I coined the term 'refraction'. ;-)

> It's interesting that many of the examples for refract are like 
> refract!(F, "F") or refract!(answer, "answer"). Would something 
> like
> Function refract(alias fun, string localSymbol = 
> __traits(identifier, fun))()
> work for you?

Not at all :-D That would return a name in the caller module. In 
the mixture you want to use only local names, and navigate from 
there.

Maybe I should change all the examples, including the unit tests, 
to avoid giving the impression that the original function name is 
a good default for the localSymbol. In most cases it's not.