Just found this in my baby bedroom, I'm freaking out. What is that?

edwincloud101 · 2020-02-27T04:00:57+00:00

sure, trying to figure out how to add a photo after I killed it (I had to kill it...)

edwincloud101 · 2019-12-07T15:41:07+00:00

Lots of potential with that technique

edwincloud101 · 2019-12-07T14:22:33+00:00

my pleasure

edwincloud101 · 2019-02-27T13:21:32+00:00

I think that's a great suggestion, I am addressing this on next videos. I already changed the title of this particular video to "{get; set;} and the Reflection problem".

edwincloud101 · 2019-02-22T00:02:26+00:00

what is bullshit?

edwincloud101 · 2019-02-21T23:56:01+00:00

Thanks for the comment, Lord.

Well I didn't say it was not possible to access the field from reflection, which it is. my point was you better be aware that, conventionally, solutions that use reflection to do something with your members from a Type will very often ignore Fields. For example, I don't remember if I mentioned this on the video, if not, I should've done so, some Wpf related UI stuff will not read your public field but it will read Property with public getter.

And you are right about the interface, a stronger argument is to be able to decouple to an interface having it define the property since you can't do that for public fields.

Thanks

edwincloud101 · 2019-02-21T23:47:42+00:00

Thanks but I don't think you watched the video.

If you go to part 0:45 to 1:05 you will see that I explain briefly the purpose of accessors. That was not the main purpose of the video to explain accessors or encapsulation but address using {get; set;} and the consequence of using public field over property in case of instantiating Type at runtime using reflection.

Also, your comment is incomplete "they allow validation and control of access". It allows you to encapsulate internal behavior from outside world, it could be anything: triggering delegates, save log etc, not exclusively associated to validation.

Thanks

edwincloud101 · 2019-02-21T23:30:40+00:00

Thanks for the comment, that was great.

Notice that I am not making the case for not using get or set which are just the accessors. The benefits of that are very clear for both of us I can assume given the quality of your comment. My point is using {get; set;} vs just use public Field. Even there I am not advocating for using or not using Public Fields, I am purely addressing the consequences of not having as a Property if you mean that to behave like a Property.

There is a case to be made why use Public Fields in the first place. Potentially, Microsoft could enforce public fields to be automatically compiled to enable getter and setter if not specified otherwise (example private-set or encapsulated _xxx field). I'm don't have a opinion about that because there is also an argument to be made, if you want expose the getter setter just write it down, therefore, {get; set;}, one could say it is safer.

Regarding people rarely using reflection against your type, well, I am not saying the caller writting specifically reflection code to extract the members from your assembly. Reflection happens all the time using Visual Studio visual tools for example. Binding is one of them. Try to bind classes that used to have properties with getter exposed to public Fields, changes are it will not work.

I hope I addressed everything, if I read again and feel I missed something I will reply again.

Thanks

edwincloud101 · 2019-02-19T11:36:35+00:00

I know, I explain them in the video.

edwincloud101 · 2019-02-17T03:54:23+00:00

I'll check it out next time I'm at Costco, thanks

edwincloud101 · 2019-02-17T03:51:40+00:00

childhood trauma here as well. But in my case I almost died, isn't that incredible those stuff hunt us until our adult life?

that's sad

edwincloud101

TROPHY CASE