On Wed, 2004-04-28 at 12:26, Dan Sugalski wrote:
>> NAME Filename, no extension or path >> EXTENSION File extension > >This represents a world-view that is not universal. Rather than making >Parrot into a lens through which system features need to be de-coded, >why not provide a set of modular native-friendly tools with which to >perform such operations?
Because you end up with 78 kinds of portability hell if you don't, as everyone rolls their own way to handle this.
Oh, don't get me wrong! I'm not saying an abstraction isn't all keen and such, I'm just wondering why we're abstracting farther out than POSIX when "the right way", as you point out has never been a matter of consensus, and many client languages will be presenting POSIX semantics through their standard libraries anyway, which they will have to massage your representation back into.
Which is why I'm fine with yanking all the filename mangling stuff from stat here.
> I'm OK with adding a TYPE to the stat array as well, though more foran "it's a file/socket/device/directory" type thing, rather than an "it's an application/x-pdf file!" thing.
Well, since no OS I know of except for MacOS/Darwin has a reliable way to determine the ACTUAL type of a file, that's wise.
MacOS does, Darwin doesn't, really. Or, rather, it's got the same sort of half-assed way of doing things as Windows does, with the extra layer of Unix file checking.
##########################################
ALTERNATE RESPONSE
This is where you go mad, right? :)
Why abstract within the arbitrary constraints of a POSIX-type stat model?
I wasn't, actually. There's a good sprinkling of VMSisms in that list, and I'm all for adding more stuff if need be. (I forgot to note the various flavors of symlink, as well as the link count in cases where it can be determined, as well as user and group of the file itself)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
