-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-17 00:51:30 +0000 Sheldon Gill <[EMAIL PROTECTED]> wrote:
> My take on that goes a little differently. It recognises that file > system calls on the underlying OS probably require a CString. Exactly > what type of CString can differ. On some platforms you'll need to > convert to a specific codepage. On others it'd be preferred UTF-8. > Having one call to convert makes it easy. I didn't realize that ... I've always assumed that the default character encoding (the one you get when you use -cString) would be the same as the character encoding used by the filesystem. That does allow for a different interpretation of the intention of the filesystemRepresentation methods, rather than that they are there to convert path semantics. > I'm interested, though. Under what use cases which don't involve archiving > paths and moving them between platforms? I can't think of an internal > breakage while remaining on the one platform. I tend to think cross platform, and while nothing springs to mind for 'good' code on a single platform, I bet there are plenty of cases where code assumes '/' as path separators in handling paths using methods other than the specific path manipulation methods (one could call that poor code). > As I noted before, I think that differences in path semantics would force you > to code at the application level when the situation dictates. > > Basically when path semantics are sufficiently between the platforms it is > going to be an issue. I have the view that trying to do it at the library > level will ultimately be more problematic. > > The reason is the implication and impact of the semantic differences is > difficult to foresee and the best response will probably vary from > application to application. Having an emulation layer in the library would > simply make it more complex and annoying to handle these cases. I don't think I agree on this point ... but I don't strongly disagree either, and I don't see how we can be sure which scheme will be harder for the app programmer to deal with except by polling the experience of a lot of developers who have produced applications running on both unix and windows ... experience which does not exist. My gut feel is that standardising on unix/posix path semantics keeps things simpler for the programmer, but if we tell them to stick to using the standard path manipulation methods it should not be necessary for them to know anything other than the implicit OpenStep path semantics defined by the NSString API (except where importing/exporting paths ... perhaps Davids suggestion of additional methods to explicity import/export windows/posix paths would help here). > I think we can handle the general case cleanly now without needing > "internal/external" transformation. > >>> If you consider my example above the current CVS solution adds code and >>> semantic complexity at the application level. Precisely what you are >>> advocating shouldn't happen. >> >> >> Not really ... >> >> 1. You are picking a special (though not unusual) case and you have to >> consider what the overall behavior is. >> 2. GNUstep is providing a helper method to make it easier, rather than >> leaving the app write to code their own. > > How is this helper method making it easier? Wooly thinking on my part ... I was starting from the assumption that given an NSString from the outside workd, you would need to convert to a C-string, then use the filesystemRepresentation method to convert from that C-string back to an NSString containing the proper internel representation of the string ... and the helper method makes that simpler ... but of course your whole point is avoiding any conversion at all. >> OPENSTEP/MacOS-x say you should use >> - -stringWithFileSystemRepresentation:length: and >> - -fileSystemRepresentationWithPath: when importing/exporting strings which >> are expected to be paths. > > I don't read it that way. I read those functions as a convenient way to move > from an NSString to an 8-bit encoding suitable for handing to OS file system > calls. Its an important difference. There is a need for it to be this way, > rather than just CString because many platforms required encoding to a > specific code page. > > In particular, I point to Win95 which was a supported OpenStep platform. > Many *nix systems were also tied to a specific 8-bit encoding. > > I also point to the telling line from Apple's Foundation documentation: > > Raises an NSCharacterConversionException if the receiver can’t be > represented in the file system’s encoding. > > Its about encoding, not internal/external transformation. I read it as pointing out that a unicode NSString for instance may contain characters which the filesystem doesn't support ... not as implying there was no transformation. If a transformation is not performed, this method seems pointless ... unless you know that the filesystem character encoding may differ from the default encoding used. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using the GPG bundle for GNUMail iD8DBQFCOTN5E6AJp3nmKIkRAucuAKCjSoafv8M7OTHsUoTIh4LgQ9cJ1wCfQGCC 4U2OAuBG+VXR55z0x/hAI8k= =fcBK -----END PGP SIGNATURE----- _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev