caches the results from Flash's describeType() call

reflect.as

package org.tinytlf.utils
{
	import flash.utils.*;

	public function reflect(type:Object, refreshCache:Boolean = false):XML
	{
		const typeCache:Dictionary = ReflectionCache.cache;

		if(!(type is Class))
		{
			if(type is Proxy)
				type = getDefinitionByName(getQualifiedClassName(type)) as Class;
			else if(type is Number)
				type = Number;
			else
				type = type.constructor as Class;
		}

		if(refreshCache || typeCache[type] == null)
			typeCache[type] = flash.utils.describeType(type);

		return typeCache[type];
	}
}

import flash.utils.Dictionary;

internal class ReflectionCache
{
	public static const cache:Dictionary = new Dictionary(false);
}

I like that it reflects the class, but I'd expect it to let me know that is the case as you can reflect an instance as well.

I like that it reflects anything passed to it. If we're in agreement about that, maybe change the parameter name to "classOrInstance"?

I can see the argument for breaking this into two single-purpose methods. IMO it's cleaner to have two methods that each do one task: "reflectClass" and "reflectInstance", at least from an API development perspective.

But in my day-to-day, I hate using super sanitized APIs. In my code, reflection is a means to an end. Making me think about whether I'm reflecting on a class or an instance seems like taking the library's problem (reflection) and making it my problem now.

it doesn't reflect anything that is passed to it. It always reflects the Class. It appears like it would reflect anything, but that isn't what the impl actually does. If it did, we wouldn't be having the conversation ;)

I may be totally off base here (and I thought hard about this before posting), but I don't see a use case for reflecting on anything other than the Class. Feel free to smack me if I'm wrong.

When you call describeType() on an instance, it leaves out static members of the Class, which I can't see being desirable if we're caching the results.

For what it's worth, agree that the implementation of the method is "different" than what the method describes, but only because this impl is the superior way of reflecting on the type.