I admit that I can't come up with a solution right now. I hope others
can see a way out of what I describe below. :-/
On 10/27/2016 11:33 AM, pontius wrote:
> On Wednesday, 26 October 2016 at 18:19:33 UTC, Ali Çehreli wrote:
>> There are different approaches but I think the solution above achieves
>> what you want:
>>
>> DefaultManager!(A) is managing an object of A
>> DefaultManager!(B) is managing an object of B
>> SomeCustomManager is managing an object of C
>>
>> Ali
>
> Thanks, your solution does work! I am still not familiar with mixins and
> haven't though about using them.
> I refactored it so that it accepts a manager instance:
>
> template ManagerRegistrationFor(T, alias mgr) {
> typeof(mgr) thisComponentMgr;
>
> static this() {
> thisComponentMgr = mgr;
> }
>
> void manage(T obj) {
> thisComponentMgr.manage(obj);
> }
> }
>
> struct GlobalManager {
> void process(T)(T t) {
> manage(t);
The problem is with that line. In the previous design,
ManagerRegistrationFor would generate a manage() template instance for T
and mix it in to the scope. As a result manage(t) would be bound to it
the correct template instance.
Now, because manager.d does not have that instance here, it needs to
refer to it with the full template name:
ManagerRegistrationFor!(T, ???).manage(t);
would work but we don't have the 'alias mgr' argument to refer to it
(hence my question marks). I don't think it's ever possible to
fully-qualify a template mixin that has an alias argument. (Yes, it
would be possible if the user also had access to the same aliased symbol.)
So, I think the problem is with the new design; we need to get rid of
that alias parameter and pass the manager object as a runtime parameter.
Ali
