Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property interception for regular properties #44

Closed
mfkl opened this issue Dec 10, 2017 · 9 comments
Closed

Property interception for regular properties #44

mfkl opened this issue Dec 10, 2017 · 9 comments
Assignees

Comments

@mfkl
Copy link

mfkl commented Dec 10, 2017

Hi,

Thanks for this package. Helpful to have netstandard support.

I've noticed the property interception only supports auto-properties.
What would it take to make it available for regular properties as well?

Cheers.

@mfkl mfkl changed the title Property interceptor for regular properties Property interception for regular properties Dec 10, 2017
@reflection-emit
Copy link
Collaborator

reflection-emit commented Dec 10, 2017 via email

@mfkl
Copy link
Author

mfkl commented Dec 10, 2017

@reflection-emit
Copy link
Collaborator

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
Copy link
Collaborator

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

@mfkl
Copy link
Author

mfkl commented Dec 11, 2017

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
Copy link
Collaborator

reflection-emit commented Dec 11, 2017 via email

@reflection-emit
Copy link
Collaborator

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

@Kazpers
Copy link

Kazpers commented Dec 21, 2017

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

@reflection-emit
Copy link
Collaborator

coming in 2.0.30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants