Re: Installation on windows (fwd)

[Richard Frith-Macdonald]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005-03-17 00:51:30 +0000 Sheldon Gill <address@hidden> 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-----