Add SkipNonPublicAttribute to skip all non-public fields/properties.

[poke]

Hey, I noticed that MT.Dialog automatically uses all properties and fields of a class when building the RootElement via reflection. As I used it for a class that has internal (private) fields for the public properties, I had all values in the generated dialog twice.

So instead of adding [Skip] to every single private field, I wanted something more global to apply to the class declaration and simply ignore all private fields. As such I created the SkipNonPublic attribute, that does exactly that. When populating the RootElement, it simply checks if that attribute is present for the class and if that’s the case then BindingFlags.NonPublic won’t be used for reading the properties/fields of the type.

It might be useful to extend this later on, so you can force separate fields/properties to appear regardless of that attribute, but I didn’t need that in this case.

Tell me what you think.
poke

[migueldeicaza]

Hello,

In general, I am not too trigger happy about extending the Reflection API extensively to cover every possible case. The reality is that attributes are a poor language to describe every possible combination that people might want to use to describe user interfaces.

A simple solution that does not bloat the executable is to load your data into a separate structure for editing and using that for your UI.

That said, this patch shows what is the problem with this approach: although there is a pull request, there is no documentation describing the changes or explaining to users why they should use this approach vs other approaches.

I believe strongly that undocumented features merely add bloat and are effectively invisible to users (with the exception of the handful of people that will read the source).

[poke]

Hey,

I understand your concerns, however I think that in OOP it is very unusual to have non-public members regulate the actual interface. While having the possibility is probably not a bad thing, not having the actual common case is a bit problematic I think (I’m not really accepting to skip every single private member).

That being said, if the lack of documentation is your only problem with this pull request, I would be more than happy to add some to explain the attribute in detail.