(Sorry for breaking the threading - with the email change I can't respond directly to the original email)
> API features > > (Optionally) The method Class.Interfaces(), and similar reflection API points, filters out IdentityObject when it is not explicitly named in the class file. Like Peter, I'm also concerned about filtering the IdentityObject interface from the reflection api. I understand there are a lot of tests with assumptions on the number of interfaces returned by these APIs and maybe even some applications with runtime behaviour changes (?) due to this. While it seems clever to filter it now - and it helps said tests & apps - is that really the model we want in the future? In 5 years is this going to be seen as the smart decision or another of the "yesterday's solutions are today's problems" variety? I think treating the injected interface as consistently as possible with non-injected ones provides the cleanest model to build in the future. It'll bring some hopefully short term pain but save us from having to explain to every user why this interface is special and only sometimes (injected vs declared) returned by the API points. --Dan
