Thanks for the input, this is good information to chew on. Like you said, I am an OOP freak as well so this is a huge deal (even though it probably shouldn’t be) to me…Thanks for the comment!

Jeff

One thing to take in mind, when it comes to interpreted languages (this doesn’t apply to compiled languages), i would advise not using getters/setters for these kind of things, since it is much slower. I know this damages the object oriented approach, and i’m also an oop freak, but when you write large systems performance should be considered in every line of code.
Calling a function would take about twice longer, since active context/scopes have to change etc.
If the methods are not used in a loop or something then the it shouldn’t bother you too much though. other than that, both techniques are fine.

It totally makes sense, I do think though that there is some CLR runtime impact while the CLR determines whether it is a get or a set function but maybe not.

I think what your question boils down to is this: Do you sacrifice developer speed & comfort for execution speed?

I don’t know the performance impact of what I am proposing above, but you do have a good point. I will have to look into the performance impacts of what I am doing. Does me saving time coding justify the performance impact…interesting…

Two thoughts: 1) I like stuff that does one thing only & does it very well. The Get/Set to me is the ultimate of this…no logic, just a straight do it….and only it. 2) I want to set the value to zero…two lines get evaluated to do this…not one…true? 3) At least in .Net VS2005 code coverage metrics around automated test scripts tend to suck when it comes to If/Then/Else constructs. Does this matter? Probably not, but again it points out that it’s potentially a less explicit way to do the work.

OK, did I just magnify my ignorance or did any of this actually make sense?