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
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 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
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
next 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
prev sibling 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