void pointer syntax

[Chris Cain]

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.