Why D const is annoying

Mehrdad wfunction at hotmail.com
Tue May 1 23:10:04 PDT 2012


"Chris Cain"  wrote in message news:nqgwunggifrgmwwhkcql at forum.dlang.org...
> What about the object do you want const? How should this object normally 
> change things? It looks like the way you've coded it, your connection will 
> get information off of a server.

I don't think you answered my question.

What I said (or meant to ask) was this:
- OK, FINE, let's say I don't know what D's const() means, then. Maybe it 
isn't suitable for what I need. I just want to know:
  _How do you specify that the function process1() won't modify its 
'student' parameter_?

Your response was this:
- "Does const(Student) mean that it shouldn't write to the server?"

To which my answer is:
- I don't know, you tell me. (?) _Should_ I use 'const' to specify this? Or 
should I use something else?

In other words:
>> Is that not the entire point of saying "const(Student)" in the first 
>> place?

You answered that by saying
> "const(Student)" means I won't change _anything_ about the object. It's 
> const. So in a sense, you can say that you won't change the fields name, 
> birthday, etc. That means you can't change the fields.

The problem with your answer is that it implies D DOESN'T SUPPORT O.O.P. 
with const!!!

If D supported OOP, then why the heck would process1() know (or _care_) how 
Student works internally?
Why (or how) should it know (or care) that Student uses a database 
connection?


Wasn't that information an implementation detail?


All process1() needs to know is the *PUBLIC INTERFACE* of Student.
And all it cares to say is: "According to the public interface of Student, 
none of the methods I will use will modify the object."
process1() has NO IDEA what goes on internally! It has NO IDEA that Student 
uses a database connection. Maybe it's a network connnection instead. Or 
maybe it's being unit-tested, and it's actually a dummy object, with no 
relation to the outside world. Or maybe it's a wrapper/proxy for another 
object.

The point is: _why should the code for process1() depend on this_?!




So, I'll ask my question again:

How should process1() tell the outside world that it will not be asking its 
parameter to manipulate itself, WITHOUT breaking the abstraction barrier and 
'peeking' into the private world of Student?



More information about the Digitalmars-d mailing list