null references redux + Looney Tunes

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:hab3r2$2pgr$1 at digitalmars.com...
> Nick Sabalausky wrote:
>>
>> There's been discussion before (I can't find it now, or remember the name 
>> for it) of type systems that allow for proper handling of things like m/s 
>> vs. m/(s*s) vs inch/min etc. I haven't actually worked with such a 
>> feature or with complex/imaginary numbers in any actual code, so I can't 
>> be sure, but I've been wondering if a type system like that would be an 
>> appropriate (or even ideal) way to handle real/complex/imaginary numbers.
>
> It better be. Complex numbers aren't that complicated of a notion. What's 
> lost in pulling them out of the language is the ability to define 
> literals. Now please name five remarkable complex literals.
>
> The feature you're referring to is called dimensional analysis.
>
>> (I've also been wondering if it might be a huge benefit for 
>> distinguishing between strings that represent a filename vs file content 
>> vs file-extention-only vs relative-path+filename, vs absolute-path-only, 
>> etc. I've been really wanting a better way to handle that than just a 
>> variable naming convention.)
>
> I don't quite think so. In fact I don't think so at all. Pathnames of 
> various flavors evolve quite a bit in many programs, and having to worry 
> about tracking their type throughout is too much aggravation to be 
> worthwhile. Last thing I'd want when manipulating pathnames would be a 
> sticker of a library slapping my wrist anytime I misuse one of its six 
> dedicated types.
>

Last thing I'd want when dealing with paths and filenames would be making 
one small mistake and getting *neither* a runtime nor a compile-time error, 
and then have the program happily trounce about the filesystem with 
corrupted names or paths (sort of like getting m/s and m/(s*s) mixed up). 
Sure, it *might* error out with an "access denied" or "file not found" or 
something like that before actually doing anything wrong, but that's far 
from guaranteed. And even if it doesn't, it might not cause real harm, but 
there are times when it could so why risk it?

I guess I just don't see why something like (fig. A) would be bad if (fig. 
B) and (fig. C) are considered good (as I certainly consider them):

-- fig A -----------
open(inFile ~ "out" ~ inFile.file ~ "log");
// As many as 4 different errors that could be caught but currently aren't.
// (But obviously all would be overridable, of course)
// Without such checking, if inFile contained "/usr/home/joe/foo/bar.dat",
// the result would be:
//   "/usr/home/joe/foo/bar.datoutbar.datlog"

// Meant to do this:
open(inFile.path ~ "out/" ~ inFile.name ~ ".log");
// Result now: "/usr/home/joe/foo/out/bar.log"
---------------------

-- fig B -----------
int add(int* a, int* b)
{
    return a + b; // Error currently caught
    // Meant:
    return *a + *b;
}
---------------------

-- fig C -----------
auto accel = velocity * time; // Error caught with that "dimensional 
analysis"
// Meant this:
auto accel = velocity / time;
---------------------

Granted, I agree that as things currently are, it might not be possible to 
write a library to handle such file/path manipulations without it being too 
unweildy for the library's prospective users. But with a good "dimensional 
analysis" system...maybe not?