Const, strings, and other things.

[Bruce Adams]

David B. Held Wrote:

> Jarrett Billingsley wrote:
> > [...]
> > 1) We're on the same team, and we have some sort of convention
> > set up for this kind of thing.
> 
> Hahahahaha!!!  I see you've never worked for a company with more than 5 
> people.  The idea that you can get even 5 people in a team in a large 
> company to agree on a "convention" is rather amusing.  If you work in a 
> company with at least 5 *teams*, you have another class of problem 
> altogether.
>
I share your pain but most organisations that acknowledge they are doing software  (rather than some kind of 'business analysis') at now accept the idea of process improvement in principle at least.
 
> > 2) You're using a library that I wrote, and it's probably well-
> > documented, or at least self-obvious, whether or not my function
> > modifies your data. 
> 
> Wow, maybe you write libraries that way, but you should take a look 
> around.  95% of software engineers don't.  Most of the code I see, I'd 
> be happy of there were *comments*, let alone documentation about 
> mutability and constness.
>
Again I share your pain. Leading by example helps. Doxygen is your friend (DIYF) etc etc. Of course in D we have contracts so you get less out of the @pre & @post part of doxygen.
 
> > (Keep in mind that even if there _is_ const available and my function is
> > not well-documented, I don't _have_ to use const, and so you don't have
> > any guarantee anyway.)
> 
> I have the guarantee that if you use const, you can't hack my data, and 
> if you don't use const, I don't have to use your code.  At the worst, I 
> will copy my data before hand and curse you for the performance hit. 
> And I can show you code bases where you will do this for your own 
> sanity; and yes, the code will make you cry.
> 
> > 3) I'm not a complete moron and actually name my functions after what
> > they do.  Face it, most people don't write functions with one name and
> > have them do something completely different, and if that's happening,
> > constness is not really going to help you with that.
> 
> So you're in the middle of an app that executes a bunch of business 
> logic, and the function is a hundred lines long and is called 
> processFoo(Foo foo, Bar bar, Baz baz).  Which of those arguments do you 
> expect to get modified and why?  Does this sound like an unreasonable 
> name?  Well, unreasonable or not, I see names like this a hundred times 
> a day.  I don't have the luxury of going around and renaming them as 
> processFooModifiesFooButNotBarOrBaz(Foo foo, Bar bar, Baz baz).
>
Don't forget we have in out and inout for documentation purposes.
I haven't tried it (mainly because its a sick idea) but presumably you can get ersatz constness with a contract:

pre {
   signature sigX = md5sum(X);
}
foo(/* const */ X) {
   ...
}
post {
  assert(sigX == md5sum(X));
}
   
This is a bit sick because its a run-time check. Might be useful for unit tests.
 
> 
> But clearly, nobody needs read-only vectors, because scientific 
> computing *always* entails modifying your matrices, tensors, etc.  And 
> if they do, they can just translate them to read-only strings instead, 
> which are faster.
>
Actually there are cases where its useful. You might want copy-on-write semantics (though those kill const though mutability). 
Another case is when you are slicing. I have seen applications in C++ where successive filters are applied to a vector-like container. In fact each filter creates a new slice of the data. (The structure is actually a tree so D array slices wouldn't work). That would make a good use case for iterators and opStar/opDeref/opSlice.
 
Regards,

Bruce.