On Wed, 2004-04-28 at 11:56, Dan Sugalski wrote:
[...]stat [PINS]x, Sy, Iz stat Px, SyThe returned PMC in the two-arg case could be a hash/array pmc and allow string-keyed access to elements. If we do that, then the names correspond to the constant names that follow.
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. (And I realized I forgot VERSION as an entry in that list)
Whether pulling out a name and extension's a good thing or not doesn't much matter, as people do it regardless, so we might as well do it properly. OTOH, I can certainly see a good case for not doing it at all and yanking all the filename stuff. That's fine too, and if that's what you're proposing I can go either way, depending on how folks weigh in. (Though I think I'll agree with you and yank them, unless there's reason put forth to not do so)
I'm OK with adding a TYPE to the stat array as well, though more for an "it's a file/socket/device/directory" type thing, rather than an "it's an application/x-pdf file!" thing.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
