Const, strings, and other things.

[Jarrett Billingsley]

"Bill Baxter" <dnewsgroup at billbaxter.com> wrote in message 
news:fhav0e$2stp$1 at digitalmars.com...

> My other convention is to name ref parameters that are meant to be output 
> like  "ref Foo something_out".  I also end up making a lot of out 
> parameters be pointers instead references, because then looking at the 
> signature I know that it must be an out parameter, because there's no 
> other reason to pass it as a pointer.

Which would be a good reason to require out at the call site, like C#.  No 
more pointer nonsense.

> Come on.  Code is poorly documented.  For 90% of open source projects out 
> there "better documentation" is in the top 5 on the TODO list.

:D

>> 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.
>
> Bad naming really has nothing to do with it.

It has something to do with it.  If you have a function like so:

void drawImage(Image i, int x, int y) ...

And Image is a class type, do you expect images that you pass in to be 
modified?  No, because that would be stupid.  It _draws an image_.  Making 
this method take a const(Image) instead is kind of beating a dead horse. 
Yes, now the compiler will enforce it but why would anyone in their right 
mind modify the passed-in image anyway?  I've never made the stupid mistake 
of going "Oh!  Why don't I modify the image data in the draw method?!  Makes 
perfect sense to me!"

And if someone really really wanted to modify the image in drawImage, at 
that point they have to have the source code, so there's nothing preventing 
them from changing that const(Image) parameter to an Image.  So I *really* 
don't see what const gets us here.