On Tuesday 02 August 2011 05:41:11 Jesse Phillips wrote: > On Mon, 01 Aug 2011 20:50:21 +0000, Jonathan M Davis wrote: > > st my pragmatic, Windows-sentric view of things :) > > > The problem with that is that then you _can't_ have something like > > "foo..bar". Granted, that's not a normal thing to do, but it would be > > problematic if it ever happened. > > You can, you just wouldn't build it with these functions. And frankly if > you are using these then you probably wouldn't want foo..bar and wouldn't > care that it ended up foo.bar or foo..bar. You just want the proper > extension on the proper name, which is what you'd get. > > > The primary danger I see with using null for no extension and empty for > > "." is > > > > assert(extension("file.") == extension("file")); > > > > That could cause problems for any program that actually runs into a file > > which ends with a ".". Now, if Linux, Windows, and Mac OS X all prevent > > files ending in a dot (which I seriously doubt), then it isn't really an > > issue. Having the difference between null and empty does make it > > possible to distinguish if you start doing stuff like > > I disagree, that assertion should pass. They both have the same > extension. If you really want to know if a file name ends in a dot, > > assert("file."[$-1] == "."); > > I just don't see a case where you'd be dealing with these too files and > care to know the extension is explicitly empty or umm just empty.
The main issue that I see is that it becomes too easy to have a program think that the names of two files are identical if you're dealing with their pieces instead of their whole. Granted, this is not exactly a normal situation, but I'd much prefer to have it handled cleanly so that programs that get into such a situation don't end up being buggy rather than declaring that two items which aren't identical as being equal. - Jonathan M Davis