Ayende @ Rahien

Refunds available at head office

Challenge: Strongly typing weakly typed code

How would you make the following code work?

public static class Security
{
	public static string GetDescription(Type entityType, Guid securityKey)
	{
		Guard.Against<ArgumentException>(securityKey == Guid.Empty, "Security Key cannot be empty");
		IEntityInformationExtractor<TEntity> extractor = IoC.Resolve<IEntityInformationExtractor<TEntity>>();
		return extractor.GetDescription(securityKey);
	}
}

You can't change the entity type parameter to a generic parameter, because you only know about it at runtime. This is usually called with:

Security.GetDescription(Type.GetType(permission.EntityTypeName), permission.EntitySecurityKey.Value);

Comments

Jon Skeet
01/21/2008 09:09 AM by
Jon Skeet

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

Ayende Rahien
01/21/2008 09:51 AM by
Ayende Rahien

Yes, IEntityInformationExtractor is only strongly typed, and I am using that as a way to separate functionalities.

Sasha Goldshtein
01/21/2008 10:11 AM by
Sasha Goldshtein

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.

Jon Skeet
01/21/2008 10:16 AM by
Jon Skeet

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

Ayende Rahien
01/21/2008 10:19 AM by
Ayende Rahien

Oh, I have a solution already, and it is based on MakeGenericMethod indeed.

Check near the end of this file:

https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-security/Rhino.Security/Security.cs

I predict a good chance for using this more than once per type, so it is worth caching it, I took it one step further and removed the use of reflection on the second iteration.

Reshef Mann
01/21/2008 10:22 AM by
Reshef Mann

Maybe refactor it to have something like:

IEntityInformationExtractorFactory extractorFactory = IoC.Resolve();

IEntityInformationExtractor extractor = extractorFactory.Resolve(entityType);

return extractor.GetDescription(securityKey);

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

Ayende Rahien
01/21/2008 10:37 AM by
Ayende Rahien

I want to keep the IEntityInformationExtractor as a generic type, and I am willing to exchange complexity in my code for simplicity in the implementation of it, since those are going to be more common

Francois Tanguay
01/21/2008 01:07 PM by
Francois Tanguay

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

generic(with entityType)

{

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

}

Max
01/21/2008 01:27 PM by
Max

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

Ted Elliott
01/21/2008 01:28 PM by
Ted Elliott

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.

Ayende Rahien
01/21/2008 01:30 PM by
Ayende Rahien

Max,

Permission is an entity. I try really hard never to make my entities generic.

Ayende Rahien
01/21/2008 01:31 PM by
Ayende Rahien

Ted,

Constraints are enforced even when you are using generics.

Mike Moore
01/21/2008 04:50 PM by
Mike Moore

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/Typesystem#Statictyping

http://en.wikipedia.org/wiki/Typesystem#Dynamictyping

http://en.wikipedia.org/wiki/Typesystem#Strongandweaktyping

Ayende Rahien
01/21/2008 08:35 PM by
Ayende Rahien

Mike, you seem to have missed the part where I have Type entityType and I need to get from there to TEntityType.

Mike Moore
01/21/2008 10:39 PM by
Mike Moore

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.)

Jon Skeet
01/22/2008 09:07 AM by
Jon Skeet

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

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.

and

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.

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.

Mats Helander
01/22/2008 10:36 AM by
Mats Helander

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).

Jon Skeet
01/22/2008 11:43 AM by
Jon Skeet

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.

Comments have been closed on this topic.