It's not entirely clear to me what you're trying to make strongly typed. Is the issue just that IEntityInformationExtractor is only strongly typed, and ditto IoC.Resolve?

You're not actually using any extra information about the entity type as far as I can see (it's effectively just a lookup key), so I'm not sure where we're going...

I suspect reflection will be involved somewhere though - you could create a generic overload containing the body of your code above, and then call it with reflection given a Type. It's not pretty, but assuming you can't change IEntityInformationExtractor (e.g. to add a nongeneric base interface) and IoC.Resolve, that's probably the most immediate option.

Mind you, it's Monday morning and I suspect I'm missing the point by quite a long way.

Jon

Use Type.MakeGenericType to construct the generic type in runtime and do your magic with reflection. You could also cache the generic types constructed to save a little performance if it's important.

MakeGenericType wouldn't help here, as it's a generic method within a nongeneric type. MethodInfo.MakeGenericMethod is the call you need, I believe.

Reflection around generics is somewhat evil in a few ways, unfortunately - particularly around generic methods - but I don't think there should be any problems in this particular case.

I'd say it's worth caching the generic method definition (i.e. the one you'll call MakeGenericMethod on) - but I'm not sure it's worth caching the closed constructed definition unless you're really likely to call it often for the same type.

I'm not sure whether Ayende already has the solution and is merely testing his readership, or whether working code would be appreciated. I'm happy to provide a sample if it would help...

Jon

Maybe refactor it to have something like:

IEntityInformationExtractorFactory extractorFactory = IoC.Resolve<IEntityInformationExtractorFactory>();

IEntityInformationExtractor extractor = extractorFactory.Resolve(entityType);

return extractor.GetDescription(securityKey);

It probably isn't strongly typed as u would like it, but it will work.

I always wished we could have a "generic scope operator" that transforms a Type argument into a generic scope:

generic<T>(with entityType)

{

return IoC.Resolve<IEntityInformation<T>>().GetDescription().

}

The direct solution would be to make Permission generic, if possible..

I'll second the wish for a "generic scope operator", working with generics using reflection is really nasty code. You wouldn't have compile time type safety though, since there would be no way to verify any constraints that the generic might have, which I guess you don't really have anyway if you're doing it through reflection.

Oren, this isn't an example of weak typing. Your code is strongly typed. Your code is also statically typed. You do not change the type system of the language by simply refering to your objects by an interface. One could argue that casting an object to a specific class is a form of dynamic typing, but even then your code has a static type check at compile time.

http://en.wikipedia.org/wiki/Strong_typing

http://en.wikipedia.org/wiki/Weak_typing

http://en.wikipedia.org/wiki/Type_system#Static_typing

http://en.wikipedia.org/wiki/Type_system#Dynamic_typing

http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing

No, I read the article and I get that. My point is that problem isn't strong vs. weak typing. You can't just take an established terms like "strongly typed" and "weakly typed" and use them to mean something else. The problem you want to solve here isn't overcoming weak typing. (I'd argue that you are trying to overcome static typing, but I think I've been pretty clear on the subject to this point and there is no need to beat that dead horse.)

'Strongly typed' and 'weakly typed' aren't terribly well established though. Everyone uses them to mean different things. From the first Wikipedia link:

<quote>

However, these terms have been given such a wide variety of meanings over the short history of computing that it is often difficult to know, out of context, what an individual writer means when using them.

</quote>

and

<quote>

I spent a few weeks... trying to sort out the terminology of 'strongly typed,' 'statically typed' 'safe,' etc., and found it amazingly difficult.... The usage of these terms is so various as to render them almost useless.

</quote>

Or, to use someone else's words: "For practical purposes, 'strong' means 'a type system which I like' and 'weak means 'a type system which I dislike' and therefore they are of little utility."

I'm not sure I'd go quite that far myself, but certainly there's a lot of ambiguity about the terms.

Jon,

I agree that the concept of "strong" vs "weak" typing is somewhat ill defined...but I would still argue that the concept of "static" vs "dynamic" typing has managed to maintain a more coherent and useful meaning.

And so when something is seemingly a fairly clearcut example of static vs dynamic typing it is better to use those terms rather than strong vs weak (which I agree ever so often reveals more about the preferences of the person using the term than the type systems they want to describe).

Yes, I'd agree about static and dynamic being reasonably well defined.

I'd say in this case that Ayende as a statically and generically typed UI, but wishes to use it in a dynamic way - i.e. some of the type information is only known at execution time. The call to MakeGenericMethod is the bridge from dynamic to static.