Re: Resolving alias
Re: Resolving alias
- Subject: Re: Resolving alias
- From: email@hidden
- Date: Sat, 25 Jan 2003 03:27:04 -0800
>
>My suggestion was to create a XXFSRef which could return an NSString but did not implement NSString methods.
>
>
Yes, I understood that. But that method has many of the same problems, since the XXFSRef is irreversibly transformed into an NSString when it is passed to unknowing API such as Foundation or AppKit:
>
>
NSArray *subpaths = [[NSFileManager defaultManager] directoryContentsAtPath:[xxfsref string]];
>
>
/ Regards, David Remahl
I don't see how this problem is avoided if one subclasses NSString. NSFileManager is still going to return NSStrings, not XXFSRefs. NSFileManager sucks anyway, Carbon's APIs are faster at doing this function on HFS+ volumes.
The old Toolbox API had the same problems before Apple deprecated APIs which used file paths as arguments. It's up to the programmer to be wary of implicit assumptions like any set of constants or variables. However Cocoa programmers can't be expected to use NSDocument for all file i/o, that's just ridiculous.
What about an XXMacFile as a temporary solution (until Apple sorts their poop out) which:
a) Uses an FSRef at runtime
b) Can be serialized as an AliasHandle
c) Can return the current path as an NSString
d) Can be initialized from an Alias, 'alis', NSString, FSRef, etc.
Optionally some faster filesystem routines for searching files could be made which use Carbon instead of POSIX and return XXMacFiles.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.