On Wednesday, 16 May 2012 at 11:12:19 UTC, Stephen Jones wrote:
> Cain: My understanding is that D is based on "no proper ways of doing things" just get the job done. The use of properties when you can use public access baffles me. So long as you are

I suppose "proper way of doing things" isn't exactly correct. There's always many ways of doing things, for instance, everyone else was suggesting a super class, which is also a correct way of doing things.

Usually in most languages when you're designing an interface to something, you specify getter and setter functions because it's a better way of encapsulating the functionality of a class.

> careful with the namespaces why would you want to  incur function overheads that could only possibly "save" the situation if you were not careful with namespaces? Another

I think this is precisely the situation most are talking about when they say "premature optimization." You're worried about the overhead of a function call on something that I would suspect (with good reason) will not take up more than 1% of your processing time.

You should worry about the function overhead on something like a double or triple nested loop on your main algorithm.

> anomaly I have never understood is why would you use multiple property calls when you could use a single function to set or get multiple items of data for the cost of a single function? It is either fashion, politics, or I am missing some piece of the puzzle.

Probably mainly experience that stuff like that can be problematic for others (and you, if you come back to it later) to read. Sure, if it makes sense (like "setPosition(123.3, 563.1)" where you can easily deduce that it's putting it at x=123.3 and y=563.1) then setting or getting multiple items of data is fine. You could use something like a struct to represent a collection of data like this and still maintain readability.

The thing you really have to understand, though, is that people don't care about it for three reasons:
1. function calls encapsulate functionality and completely avoid problems like you're having.
2. It's already ridiculously fast. Generally speaking, function calls will not be the thing slowing your program down. Especially if you don't even know how much time your code takes as is.
3. Generally programmer time is much more expensive than computation time. For instance, do you honestly think a programmer could spare as much time as you've taken trying to figure out how to save the cost of a few function calls when he has to get this stuff done?

The beauty of using properties is that you can mostly work your application like it's setting the variables directly. If later on you decide you _need_ it to directly set the variables, you _could_ just change the interface to the super class solution to expose the bare variables.