In a custom FxCop rule how do you find all implementation of a given InterfaceNode?
If there is easy way, can I at least get a list of all loaded types to find it out myself?
Answering my own question. I couldn't find any public helper that gives me all loaded assemblies and types, but there is an internal property Microsoft.FxCop.Sdk.InternalUtilities.LoadedAssemblies in the FxCopSdk.dll which can be used to list all loaded types. From there it is pretty intuitive to find implementations of an interface.
Related
Given Object1 and Object2, are there any techniques for determining if they both implement a common interface? No problem if the interface is known at compile time (use typeof ... is [known interface]), but what about if interface isn't specified at compile time?
Specific use case is implementing a strongly typed collection object. I only want to add Object2 if it shares a common interface as Object1. Typename doesn't work since it returns the underlying object type and I may have two distinct objects each implementing ISomeInterface but on different underlying classes.
An example that doesn't quite work can be found here (as it relies on typename but that doesn't allow for interface comparisons)
Specifically, expanding the IsTypeSafe function found here on CodeReview but adapted so that if an object supports an interface common to all previously added items, it can be added to the list.
Specific question: is there a way to determine if two objects both implement a common interface that is unspecified at compile time?
I got really confused with your "unspecified at compile time" wording, but the crux of your question is here:
if an object supports an interface common to all previously added items, it can be added to the list.
In other words, you're asking if there's a way to do this in VBA (pseudo-mish-mash of VBA/C#):
isOk = item.Type.Interfaces.Any(i => other.Type.Interfaces.Contains(i))
In order to be able to inspect an object variable's implemented interfaces, you'd need to be able to inspect its type at run-time. This ability is called "reflection"... and VBA can't do that.
Rubberduck (disclaimer: I manage this OSS VBIDE add-in project) has a COM API that might eventually grow to support exactly that though (it's open-source, implement it - we are very happy to take pull requests!), but in order to work its magic it needs to literally parse and resolve the entire project and all its references, which means using reflection for what you'd like to use it for, would be a massive performance hit.
A "type-safe" List class in VBA is basically smokes & mirrors. Sorry!
I'm trying to do some polymorphic deseralization of JSON using Jackson, however the list of subclasses is unknown at compile time, so I can't use a #JsonSubtype annotation on the base class.
Instead I want to use a TypeIdResolver class to perform the conversion to and from a property value.
The list of possible subclasses I might encounter will be dynamic, but they are all registered at run time with a registry. So I would appear to need my TypeIdResolver object to have a reference to that registry class. It has to operate in what is essentially a dependency injection environment (i.e I can't have a singleton class that the TypeIdResolver consults), so I think I need to inject the registry class into the TypeIdResolver. The kind of code I think I want write is:
ObjectMapper mapper = new ObjectMapper();
mapper.something(new MyTypeIdResolver(subclassRegistry));
mapper.readValue(...)
However, I can't find a way of doing the bit in the middle. The only methods I can find use java annotations to specify what the TypeIdResolver is going to be.
This question Is there a way to specify #JsonTypeIdResolver on mapper config instead of annotation? is the same, though the motivation is different, and the answer is to use an annotation mixin, which won't work here.
SimpleModule has method registerSubtypes(), with which you can register subtypes. If only passing Classes, simple class name is used as type id, but you can also pass NamedType to define type id to use for sub-class.
So, if you do know full set, just build SimpleModule, register that to mapper.
Otherwise if this does not work you may need to resort to just sharing data via static singleton instance (if applicable), or even ThreadLocal.
Note that in the end what I did was abandon Jackson and write my own much simpler framework based on javax.json that just did the kinds of serialisation I wanted in a much more straightforward fashion. I was only dealing with simple DTO (data transfer object) classes, so it was just much simpler to write my own simple framework.
I want to provide some functionality for compiling sources of a specific kind (e.g. java).
As the process of compilation needs additional information i need to give in some more arguments and not only the sourcefile. E.g. working directory, compiler parameters and so on.
There are two ways in my mind how to design it:
Using OOP, that means creating a compiler class, saving the
additional arguments when constructing a specific compiler object
that can then be used for compiling by just providing the sourcefile
Not creating a class for creating objects but just a (static final?)
closure in a class and then using curry to pass in the needed
arguments and returning another compile function which can then be
provided by for example just the sourcefile to compile it
What are the pros and cons? Is there maybe an even better way to get things done?
According to me it only depends on if this should be done well or it's just a kind of a proof of concept. If there will be multiple source files with different types, then it's better to create well-designed, robust class hierarchy. Otherwise You can use a bunch a predefined closures if suites your needs.
Mind the fact that these two solutions are not mutually exclusive. You can still create a robust class hierarchy that will be using predefined closures internally.
Is type checking considered bad practice even if you are checking against an interface? I understand that you should always program to an interface and not an implementation - is this what it means?
For example, in PHP, is the following OK?
if($class instanceof AnInterface) {
// Do some code
}
Or is there a better way of altering the behaviour of code based on a class type?
Edit: Just to be clear I am talking about checking whether a class implements an interface not just that it is an instance of a certain class.
As long as you follow the LSP, I don't see a problem. Your code must work with any implementation of the interface. It's not a problem that certain implementations cause you to follow different code paths, as long as you can correctly work with any implementation of the interface.
If your code doesn't work with all implementations of the interface, then you shouldn't use the interface in the first place.
If you can avoid type checking you should; however, one scenario where I found it handy, was we had a web service which took a message but the contents of the message could change. We had to persist the message back into a db, in order to get the right component to break the message down to its proper tables we used type checking in a sense.
What I find more common and flexible then if ($class instanceof SomeOtherType) is to define an IProcessing strategy for example and then using factory based on the type $class create the correct class.
So in c# roughly this:
void Process(Message msg)
{
IProcessor processor=ProcessignFactory.GetProcessor(msg.GetType());
processor.Process(msg);
}
However sometimes doing this can be overkill if your only dealing with one variation that won't change implement it using a type check, and when / if you find you were wrong and it requires more checks then refactor it into a more robust solution.
In my practice any checking for type (as well as type casting) has always indicated that something is wrong with the code or with the language.
So I try to avoid it whenever possible.
Run-time type checking is often necessary in situations where an interface provides all the methods necessary to do something, but does not provide enough to do it well. A prime example of such a situation is determining the number of items in an enumerable sequence. It's possible to make such a determination by enumerating through the sequence, but many enumerable objects "know" how many items they contain. If an object knows how many items it contains, it will likely be more efficient to ask it than to enumerate through the collection and count the items individually.
Arguably, IEnumerable should have provided some methods to ask what it knows about the number of items it contains [recognizing the possibility that the object may know that the number is unbounded, or that it's at most 4,591 (but could be a lot less), etc.], but it doesn't. What might be ideal would be if a new version of IEnumerable interface could be produced that included default implementations for any "new" methods it adds, and if such interface could be considered to be implemented by any implementations of the present version. Unfortunately, because no such feature exists, the only way to get the count of an enumerable collection without enumerating it is to check whether it implements any known collection interfaces that include a Count member.
I am implementing an HTTP Module in ASP.NET to identify geographical information based on the request's IP (a GeoIP module) and I will need to place things somewhere so the handler or later modules can inspect.
Except HttpContext.Items (which is not type-safe) is there some other decent alternative?
It depends what you want to store. Type safety can only really apply if you are using one type of item within a collection so none of the generic stores will be applicable for you.
Maybe it would be a better idea to implement a helper class to write and read from a subset of HttpContext.Current.Items in a type safe manner?