Here's a question that I had recently, that's sort of related to your thread. I was writing code that had to be optimized for speed, and one of the things I did to speed things up was use immutable objects. I made the properties of each of these objects into readonly fields, and assigned their values from the constructor methods. I thought that this would result in faster access times, and in my microbenchmarks (on my laptop only) it did seem to help slightly. Am I just smoking crack, or can this actually offer a performance benefit? Also, what's the relative cost of a property get/set versus a method invocation?
I don't think that normal arguments for encapsulation apply here, to support hiding the variables with property getters. It's the same to calling code, yes? I don't know about compilation differences, though-- I will buy that. But what if I am able to put a stake in the ground on certain fields, and say they'll never be changed? Even though I am presenting this argument, the former Java programmer in me shudders that I can even suggest making fields public. Then again, there aren't such nice things as property getters in Java, which negate the semantic differences... Thoughts? Jeff P.S. I would like to start playing around with the IL. Can anyone recommend any good starting places, tools, or books? (Besides the obvious ildasm.exe, etc.) Thanks a lot. --- Thomas Tomiczek <[EMAIL PROTECTED]> wrote: > What about later extensibility? Do you want all the clients of your > objects to HAVE to recompile? > > Also, some ams have rules. Our rules say: NO PUBLIC VARIABLES. NEVER. > > :-) > > Leaves us with a lot of properties. > > That said - I don't think we need a keyboard,j ust some automatism to > write this code for us. > > Thomas Tomiczek > THONA Software & Consulting Ltd. > (Microsoft MVP C#/.NET) > > > -----Original Message----- > > From: Moderated discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED] On Behalf Of Damien Guard > > Sent: Dienstag, 21. Oktober 2003 12:36 > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Do properties need a 'holder' keyword? > > > > >I find it is very common to have a private field that > > properties use to > > hold there value, like > > >get{return holder;}set{holder=value;} > > > > If that's all you are doing in a property's methods then why > > not remove the property and make the private field public? > > > > [)amien > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > NEW! ASP.NET courses you may be interested in: > > > > 2 Days of ASP.NET, 29 Sept 2003, in Redmond > > http://www.develop.com/courses/2daspdotnet > > > > Guerrilla ASP.NET, 13 Oct 2003, in Boston > > http://www.develop.com/courses/gaspdotnet > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > > > > > =================================== > This list is hosted by DevelopMentorŪ http://www.develop.com > NEW! ASP.NET courses you may be interested in: > > 2 Days of ASP.NET, 29 Sept 2003, in Redmond > http://www.develop.com/courses/2daspdotnet > > Guerrilla ASP.NET, 13 Oct 2003, in Boston > http://www.develop.com/courses/gaspdotnet > > View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
