www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Map type to class instance at compile-time

reply pontius <pontius example.com> writes:
Apologies for the long post or stupid questions, I only started 
to learn D today.
I have a use case where various types (A, B, C) need to be 
associated with instances of different classes (ManagerA, 
ManagerB, ManagerC). A certain object (globalManager) should 
redirect operations on those types to their respective managers 
at compile-time. I intend to use it in the following way:

class GlobalManager(TypeToManagerMapping) {
     public void process(T)(T t) {
         // Must be resolved at compile-time
         TypeToManagerMapping.getManagerForType(T).process(t);
     }
}

// All these types can be completely unrelated, i.e. no base 
classes
struct A {}
alias ManagerA = DefaultManager!(A)
struct B {}
alias ManagerB = DefaultManager!(B)
struct C {}
alias ManagerC = SomeCustomManager;

// Calls to globalManager should be redirected to these at 
compile-time
auto mgrA = new ManagerA();
auto mgrB = new ManagerB();
auto mgrC = new ManagerC();

// This is my problem, see below
alias TypeToManagerMapping = ...;

// Pass the mapping as a template parameter so that it can be 
resolved at compile-time
auto globalManager = new GlobalManager!(TypeToManagerMapping)();

// The following is the module user's code.
// The user may not be aware of mgrA, mgrB, etc, only of 
globalManager

A a = A();
B b = B();
C c = C();

// Redirection to managers in the following operations
// must be resolved at compile-time

// Should turn into mgrA.process(a), etc
globalManager.process(a);
globalManager.process(b);
globalManager.process(c);

So, I need to map a type (e.g. A) to an instance (e.g. mgrA). I 
have managed to implement a compile-time map from type to value 
(by the way, how do I get rid of TValue argument in 
TypeValuePair? it can be deduced, but I failed to get it working 
with an eponymous template):

struct TypeValuePair(TKey_, TValue, TValue value_) {
	alias TKey = TKey_;
	static const TValue value = value_;
}

struct StaticMap(THead, Args...) {
	template get(T) {
		static if (Args.length < 0) {
			static assert(false, "StaticMap does not contain this key");
		} else static if (is(T == THead.TKey)) {
			alias get = THead.value;
		} else {
			alias get = StaticMap!(Args).get!(T);
		}
	}
}

This works nicely for mapping types to literal values:

alias TypeMap = StaticMap!(
	TypeValuePair!(string, string, "a string"),
	TypeValuePair!(int, string, "an int"),
	TypeValuePair!(bool, string, "a bool")
);
writeln(TypeMap.get!(int));

But fails with "variable cannot be read at compile-time" when I 
try to pass a class instance in there:

alias TypeMap = StaticMap!(
	TypeValuePair!(A, ManagerA, mgrA)
);
TypeMap.get!(A).process(a);

So, how do I resolve type-to-instance mapping at compile-time so 
that my user only needs to call globalManager and not know 
anything about individual managers?

I could easily do this with typeid() calls, but the solution must 
be purely compile-time (for learning purposes; let's say my code 
is performance-critical and the lookup would take considerable 
amount of time).
Oct 26 2016
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/26/2016 10:48 AM, pontius wrote:
 Apologies for the long post or stupid questions, I only started to learn
 D today.
Looking at what you've achieved in one day, we really need you! :)
 I have a use case where various types (A, B, C) need to be associated
 with instances of different classes (ManagerA, ManagerB, ManagerC). A
 certain object (globalManager) should redirect operations on those types
 to their respective managers at compile-time. I intend to use it in the
 following way:

 class GlobalManager(TypeToManagerMapping) {
     public void process(T)(T t) {
         // Must be resolved at compile-time
         TypeToManagerMapping.getManagerForType(T).process(t);
     }
 }

 // All these types can be completely unrelated, i.e. no base classes
 struct A {}
 alias ManagerA = DefaultManager!(A)
 struct B {}
 alias ManagerB = DefaultManager!(B)
 struct C {}
 alias ManagerC = SomeCustomManager;

 // Calls to globalManager should be redirected to these at compile-time
 auto mgrA = new ManagerA();
 auto mgrB = new ManagerB();
 auto mgrC = new ManagerC();

 // This is my problem, see below
 alias TypeToManagerMapping = ...;

 // Pass the mapping as a template parameter so that it can be resolved
 at compile-time
 auto globalManager = new GlobalManager!(TypeToManagerMapping)();

 // The following is the module user's code.
 // The user may not be aware of mgrA, mgrB, etc, only of globalManager

 A a = A();
 B b = B();
 C c = C();

 // Redirection to managers in the following operations
 // must be resolved at compile-time

 // Should turn into mgrA.process(a), etc
 globalManager.process(a);
 globalManager.process(b);
 globalManager.process(c);
void report(M, T)() { import std.stdio : writefln; writefln("%s is managing an object of %s", M.stringof, T.stringof); } class DefaultManager(T) { void manage(T t) { report!(typeof(this), T); } } class SomeCustomManager { void manage(C c) { report!(SomeCustomManager, C); } } struct A {} alias ManagerA = DefaultManager!(A); struct B {} alias ManagerB = DefaultManager!(B); struct C {} alias ManagerC = SomeCustomManager; /*/ You can use this: alias TypeToManagerMapping = AliasSeq!(A, ManagerA, B, ManagerB, C, ManagerC); However, if you already have symbolic mapping from T to ManagerT, you can use string mixins as well */ template ManagerRegistrationFor(T) { // Just a couple of convenience functions string managerType() { return "Manager" ~ T.stringof; } string managerName() { return "mng" ~ T.stringof; } // This is the manager object mixin(managerType() ~ ' ' ~ managerName() ~ ';'); // This is the initialization of it static this() { mixin(managerName() ~ `= new ` ~ managerType() ~ ';'); } void manage(T obj) { // Dispatches to the manager mixin(managerName() ~ ".manage(obj);"); } } struct GlobalManager { void process(T)(T t) { manage(t); } } GlobalManager globalManager; mixin ManagerRegistrationFor!A; mixin ManagerRegistrationFor!B; mixin ManagerRegistrationFor!C; /* The above could be specified with an AliasSeq (uncompiled): alias ManagedTypes = AliasSeq!(A, B, C); This loop can be inside a template like RegisterManagedTypes foreach (T; ManagedTypes) { mixin ManagerRegistrationFor!T; } And then: mixin RegisterManagedTypes; */ void main() { A a = A(); B b = B(); C c = C(); globalManager.process(a); globalManager.process(b); globalManager.process(c); } 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
Oct 26 2016
parent reply pontius <pontius example.com> writes:
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); } } GlobalManager globalManager; mixin ManagerRegistrationFor!(A, new ManagerA()); const ManagerB mgrB = new const ManagerB(); mixin ManagerRegistrationFor!(B, mgrB); mixin ManagerRegistrationFor!(C, new ManagerC()); I have an issue with incapsulating this code in another module, though. I should have probably clarified that Managers can be defined both inside my library and in separate modules by my library users. If I move template ManagerRegistrationFor and struct GlobalManager to e.g. manager.d and attempt to define ManagerA,B,C and call ManagerRegistrationFor(...) in main.d, it doesn't compile: 1) Error: template instance manager.GlobalManager.process!(A) error instantiating This happens 3 times in main.d at globalManager.process(a); and the other to .process calls. 2) Error: undefined identifier 'manage', did you mean module 'manager'? This error points to the body of GlobalManager.process in manager.d (it also occurs 3 times). What would be the right way to incapsulate this mixin and GlobalManager to a separate module?
Oct 27 2016
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 27 2016
parent pontius <pontius example.com> writes:
On Thursday, 27 October 2016 at 19:16:03 UTC, Ali Çehreli wrote:
 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
Heck, I should have noticed that the overloads are created in the wrong module. I would like to use alias here, because instantiation via string mixin places arbitrary restrictions on my users' constructors. I hope a better way is possible. Nevertheless, thank you for your help, the examples were very useful for me.
Nov 05 2016