www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - More constants in std.string?

reply simendsjo <simen.endsjo pandavre.com> writes:
\r and \n is used many times throughout std.string (and probably other 
modules like file).
I assume defining constants were considered:
const CR = '\r';
const LF = '\n';

So why isn't constants used instead?
Aug 09 2010
next sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Monday, August 09, 2010 17:24:47 simendsjo wrote:
 \r and \n is used many times throughout std.string (and probably other
 modules like file).
 I assume defining constants were considered:
 const CR = '\r';
 const LF = '\n';
 
 So why isn't constants used instead?

Well, what would that really save or help? They're totally unambiguous and easily typed with the keyboard. Not to mention, if you were going to do that, you'd probably define them like so enum CR = "\r"; enum LF = "\n"; Using enum for manifest constants is the more typical way to do it in D (it also forces compile-time evaluation of their value), and we want to avoid using individual chars or wchars, so pretty much all string-related functions take strings even if you'd think that they'd take a character of some kind (though if they were to take a character type, it would have to be dchar). In any case, the values for these constants never change regardless of the machine - unlike something like path.sep which indicates the path separator for the machine and changes depending on which machine you compile on. For it to be worth making "\r" and "\n" constants, you have to gain something from it, and I don't think that there's much to be gained. Not to mention, you can always make more constants, and you have to stop somewhere, so you're always going to find something that _could_ be a constant and isn't. - Jonathan M Davis
Aug 09 2010
parent reply simendsjo <simen.endsjo pandavre.com> writes:
On 10.08.2010 02:46, Jonathan M Davis wrote:
 On Monday, August 09, 2010 17:24:47 simendsjo wrote:
 \r and \n is used many times throughout std.string (and probably other
 modules like file).
 I assume defining constants were considered:
 const CR = '\r';
 const LF = '\n';

 So why isn't constants used instead?

Well, what would that really save or help? They're totally unambiguous and easily typed with the keyboard. Not to mention, if you were going to do that, you'd probably define them like so enum CR = "\r"; enum LF = "\n"; Using enum for manifest constants is the more typical way to do it in D (it also forces compile-time evaluation of their value), and we want to avoid using individual chars or wchars, so pretty much all string-related functions take strings even if you'd think that they'd take a character of some kind (though if they were to take a character type, it would have to be dchar). In any case, the values for these constants never change regardless of the machine - unlike something like path.sep which indicates the path separator for the machine and changes depending on which machine you compile on. For it to be worth making "\r" and "\n" constants, you have to gain something from it, and I don't think that there's much to be gained. Not to mention, you can always make more constants, and you have to stop somewhere, so you're always going to find something that _could_ be a constant and isn't. - Jonathan M Davis

I agree. I really don't thing it makes a difference or not.. '\r' is always that symbol no matter if it's a iPhone, embedded device or supercomputer. It's more that it's more error prone to write it than CR (ooops! compiler error!). If I wrote '\e' in a large switch and haven't tested all code paths.. Yes, shame on me, but I really meant \r! A constant gives me an at once. D is all about removing common, stupid programmer errors like I do, right? :) It's just nitpicking and not a big deal at all. I can only remember once I've been bitten by one of these (not in D), but I quickly found the source.
Aug 09 2010
parent reply simendsjo <simen.endsjo pandavre.com> writes:
On 10.08.2010 03:15, Jonathan M Davis wrote:
 On Monday, August 09, 2010 18:00:44 simendsjo wrote:
 I agree. I really don't thing it makes a difference or not.. '\r' is
 always that symbol no matter if it's a iPhone, embedded device or
 supercomputer. It's more that it's more error prone to write it than CR
 (ooops! compiler error!). If I wrote '\e' in a large switch and haven't
 tested all code paths.. Yes, shame on me, but I really meant \r! A
 constant gives me an at once. D is all about removing common, stupid
 programmer errors like I do, right? :)

 It's just nitpicking and not a big deal at all. I can only remember once
 I've been bitten by one of these (not in D), but I quickly found the
 source.

You might be less likely to mistype CR as something valid, but the compiler won't care whether you write CR or "\e". It's just going to replace CR with "\r" everywhere anyway. You can only do so much to save the programmer from their own stupidity and carelessness. Using constants as an attempt to reduce typos is not a good move IMHO. The language itself does try and reduce the opportunity for stupid programming errors, but it doesn't protect against everything, and I think that it's generally only in the cases where it's obviously a benefit that it actually tries to protect you from yourself. - Jonathan M Davis

Yeah, I know. I'm really just pointing out very small things here as I try to learn the language and library. Still.. I do think that static checking is a very good way of eliminating many common bugs. This might have been a bad example. I've coded several non-trivial applications in scripting languages, and more often than not, I _know_ what kind of objects my functions accepts... Why a runtime error when you can have a compile time error?
Aug 09 2010
parent bearophile <bearophileHUGS lycos.com> writes:
simendsjo:

 Why a runtime error when you can have a compile time error?

Because using the static type system has various kinds of costs that some people in some situations are not willing to pay. Bye, bearophile
Aug 10 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Monday, August 09, 2010 18:00:44 simendsjo wrote:
 I agree. I really don't thing it makes a difference or not.. '\r' is
 always that symbol no matter if it's a iPhone, embedded device or
 supercomputer. It's more that it's more error prone to write it than CR
 (ooops! compiler error!). If I wrote '\e' in a large switch and haven't
 tested all code paths.. Yes, shame on me, but I really meant \r! A
 constant gives me an at once. D is all about removing common, stupid
 programmer errors like I do, right? :)
 
 It's just nitpicking and not a big deal at all. I can only remember once
 I've been bitten by one of these (not in D), but I quickly found the
 source.

You might be less likely to mistype CR as something valid, but the compiler won't care whether you write CR or "\e". It's just going to replace CR with "\r" everywhere anyway. You can only do so much to save the programmer from their own stupidity and carelessness. Using constants as an attempt to reduce typos is not a good move IMHO. The language itself does try and reduce the opportunity for stupid programming errors, but it doesn't protect against everything, and I think that it's generally only in the cases where it's obviously a benefit that it actually tries to protect you from yourself. - Jonathan M Davis
Aug 09 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Monday, August 09, 2010 18:21:21 simendsjo wrote:
 Yeah, I know. I'm really just pointing out very small things here as I
 try to learn the language and library. Still.. I do think that static
 checking is a very good way of eliminating many common bugs. This might
 have been a bad example. I've coded several non-trivial applications in
 scripting languages, and more often than not, I _know_ what kind of
 objects my functions accepts... Why a runtime error when you can have a
 compile time error?

Well, fortunately, D is statically-typed and generally designed to catch bugs at compile time rather than runtime. It doesn't always succeed (dmd omniscient after all), but a lot more errors are going to be found at compile time than runtime than you'd get with many other languages - especially scripting languages which tend to be dynamically typed. - Jonathan M Davis
Aug 09 2010