The null ref exceptions would be possible. Previously Obtics all the time implicitly checked for null values. It was necessairy because Obtics would break if such an exception was raised. If all is right this sort of exceptions shoudn't break the Obtics
kernal anymore and since the implicit checks weren't helpfull for performance I removed them. Now programmer should check for null references (like in normal code) and/or handle the resulting Exceptions via new extension methods.
I think the trick you mention specifically deals with binding to anonymous types. Using anonymous types in transformed expressions leads to problems in partially trusted invironments. The trick would help but it would require the DEFINING assembly (not the
obtics assembly) to give 'internals visible permission'.
The Concrete methods deal with another problem that is specific for Silverlight (and less so for WPF). Both systems look in the object hierarchy for a given property to bind to. In WPF you can specifically indicate that it should bind to a property on an
interface but in Silverlight this is not possible. I don't want to expose the internals of Obtics (make all transformation object classes and hierarchies public) so the solution was to use an explicit and public patch object that would proxy an interface
and pass it's properties through via concrete and public class properties.
It could be an idea to expose the internal classes of obtics to the WPF or Silverlight assemblies so that they can bind to the internal properties. I need to experiment with that; thanks for the tip.. :-)