While I understand that your code is suffering in what it can do
because Windows is the least common denominator, what you suggest is
a horribly bad idea. FSRefs exist because they don't depend on the
path. That means they don't suffer from the fragile nature of paths.
Paths break if the user moves or renames a file or any component of
the files path. If at all possible, it's usually recommended to avoid
them or get paths Just in Time if there is no other way.
Sadly, Paths are becoming the norm, even with their huge limitations
because in a lot of cases Cocoa is the LCD on OS X. And cocoa has
virtually no file handling APIs that work with anything but paths.
NSDocument being a notable exception that stores an FSRef internally.
And what other systems do isn't the right way to deal with files.
It's just what they do.
Pascal strings haven't been recommended in use in OS X since its
inception. Most of the APIs that used Pascal strings are deprecated
and if not have replacements that don't rely on Pascal Strings (such
FSRef replacing FSSpec).
Ack, at 9/30/05, Denis @ TheOffice said:
Make high end file functionality.
That means no FSRef, no FSSpec, no ParID, vRefnum... Just bare bones
Path and file names in two
flavor UniChar or UTF-8, ASCII at the limit.
Keep those internally to your self... That is what other systems do.
Make it a black box like you
did for CFString...
And Get rid of the damn Pascal string... It was a bad idea in the
70-80's and it still is.
That would help yourself.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
It's either this, or imagining Phil Schiller in a thong.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
