Property interception for regular properties

[capgemini]

Property interception for regular properties

[reflection-emit]

coming in 2.0.30

[reflection-emit]

Hi, My problem is that I need the backing field so that I can allow the interceptor to set it or read it without causing Stackoverflows. So actually what I need is a really good backing field detection. Thats not very trivial though… Regards

[mfkl]

This link could be of interest: https://github.com/tom-englert/AutoProperties.Fody/blob/master/BackingFieldAccess.md

[reflection-emit]

Thanks for the link... But I don't think this is the same issue... Getting the backing fields of Auto-Properties is very easy, because of their naming convention. But getting the backing field of "custom" properties is another thing... Constructs like the following (Which I have seen already) make it a lot harder:

private int languageIndex;
public string LanguageName { get{ return Language[languageIndex]; } }
public int? LanguageIndex
{
   get { return languageIndex; }
   set {
            if(value == null || Language.Length < value)
                   return;
           languageIndex = value;
          }
}

The first property is something I wont be able to intercept at all, because I would have a hard time getting the backing field. I can surely just pass Language[languageIndex] to the interceptor. This requires a different logic than the current one though.
The second property is easier... I can get the backing field from the getter... I have only to make sure that it also exists and used in the setter. But there will be some stuff going on with Nullable in there, which does not make it easy to get the proper field.
That is only one example of all possibilities that can be done with getter and setter... I can implement some of the more standard ones... Like the following:

private string backingField;
public string Property
{ 
   get{ return backingField; }
   set{ 
             if(backingField == value)
                return;
             backingField = value;
        }
}

This case is actually easy to detect.

[reflection-emit]

Btw.. I did some testing... The last example works with the current implementation. I may add it in the next release.

[mfkl]

Great. Is support for constructor interception something you may be interested in?
FYI, I'm using your package to do native DLL version checks with attributes. https://github.com/mfkl/LibVLCSharp/blob/master/LibVlcSharp/LibVLC.cs

[reflection-emit]

Cool… It is always nice to see how it is used. About the constructor interception.... I am actually planing to add that, but I am still unsure what to implement… I mean should be there a try-catch… Does it make sense to have a try-catch… Should I add it before or after base class call… Should it be around the original constructor body…. And so on… Maybe you can enlist in a new issue everything you expect from a constructor interception, because I haven‘t actually needed one and I am unsure about the requirements.

…

________________________________ Firma: Capgemini Deutschland GmbH Aufsichtsratsvorsitzender: Antonio Schnieder • Geschäftsführer: Dr. Michael Schulte (Sprecher) • Jost Förster • Dr. Peter Lempp • Dr. Volkmar Varnhagen Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

[reflection-emit]

I will leave this open for a maybe better implementation of backing-field detection.

[Kazpers]

Perhaps focus on property interception for computed properties (ie. no backing field)?