TypeInfo or TypeMisInfo

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Wed Oct 19 01:09:19 PDT 2011


Now, that I completely understood how shared data works, I ran into
the second most annoying thing.
Maybe I don't get it either, so I'll just say what i find wrong and
ask how can it be dealt with.

I'm making a system, which converts a given class into a typeless
callback handler by scanning it's non-static shared methods and
storing their delegates in a single place.
The (rather slow) prototype uses Variant (no performance-critical code
would be stupid enough to use Variant) to store statically typeless
data (return value and the parameters).
I cast away the exact type of the delegates and store it in a struct
along with TypeInfo objects for the return type and the parameters
(because the TypeInfo for delegates is broken and it doesn't contain
info about parameters).
I put a template opCall in this struct, which takes variadic
parameters and packs them into an array of variants to pass to the
callback, performing an optional type-check and synchronization.
The struct is intended to wrap shared class or struct methods in a
uniform type-safe, thread-safe dynamically typed wrapper to be used in
modular architecture, where modules are arrays of such structs.

In order for this struct to make any sense, i need to make it shared,
so it's opCall can be called from across thread boundaries (which was
the whole point).
But if I make the struct shared, that means, I need to make TypeInfo
objects shared as well, which is impossible, because there's no way to
obtain a shared TypeInfo.
Another attempt to make the struct immutable (it really is immutable
by it's nature) also failed, because none of TypeInfo's methods
(including the toString, which i use almost exclusively) are
accessible.

My question is: Why isn't TypeInfo immutable? It doesn't make any
sense to have a mutable type info. Besides, Being immutable also means
being shared (it also doesn't make any sense to have thread-local
TypeInfo).


More information about the Digitalmars-d mailing list