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.
