Am 25.07.2005 um 16:21 schrieb Seth Dillingham:
> My main point was that the scripting interface in Frontier has largely
> been defined to hide the differences between the platforms.
I don't see it that way. Untill V5 frontier was mac only. If it were to
define a platform independent file path representation, that still has
to be done. There are too many scripts with ifMac/ifWin cases &
If you want platform independence you're free to define some abstract
framework[*] for it. I'm into the details that framework will
The category is named carbon because these are carbon only. It also
acts as a playground. If they become stable and are accepted they could
be integrated into the file category. I'm not asking for including a
carbon category into the main trunk.
I have them because I need them.
I will have them in my kernel at least till all file.* verbs can handle
long filenames. That's a lot of plumbing...
> I think it would be better to enhance the existing verbs to make better
> use of unix-style paths and unicode where possible, rather than
I regard unix-style path only as an option.
Unicode is a necessity. I'm thinking about using CoreFoundation. It's
just a thousand places in the source...
> creating a new set of mac-only file-handling verbs. I'd rather add the
> functionality of these long-path verbs to what we already have (such as
> automatic coercion between filespec and filepath, and alias on mac).
filespec, string & alias. filepath is a string.
As I said before: That's a lot of work. I simply don't see it done.
What's currently happening in kernelwork? Not much on this list... So
volumename on mac
driveletter on win
???(perhaps mount point) on linux
- ordered list of directory names
goes along with changing the kernel to use these and with some library
x = file.getPlatformPath(aFrontierPath)
x = file.getMacPath(aFrontierPath)