Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]

[Sheldon Gill]

> > > > I'm working on string methods now as part of my path & win32 effort, 
> > > > if anyone is interested.
> > >
> > > I'd be interested in knowing what exactly .... as I have a load of 
> > > uncommitted windows path changes on my system (I was waiting for 
> > > feedback on the last tranch of changes), and I'm also occasionally 
> > > updating bits and pieces to match MacOS-X API.
> >
> > Hmm...
> >
> > In no particular order and off the top of my head:
> >
> > * NSHomeDirectoryForUser() now finds other users on Win32
> >
> > * Additional directory keys for NSSearchPath() including
> >   all the new Tiger keys.
> >
> > * GSSearchPath() for porting/compatibility
> >
> > * New implemenation of SearchPathForDirectories; O(1)
> >     Very much faster and more readily extensible
> >
> > * Paths from registry in Win32 for mingw32 native
> >
> > * standardised, improved way to determine win32 IsExecutableFile
> >
> > * hide/show extensions on win32 in sync with Explorer
> >
> > * Flexibilty improvements in FS layout for platform-specific packaging
> >   Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}
> >
> > * Some string methods do better argument checking and/or raise an
> >   exception when invalid/nil
> >
> > * Documentation for all this and more
>
>
> Wow ... that's a lot of changes.

That's actually quite well contained, really. There is more of my 
NSPathUtilities bit and a few more Win32 support routines. {Strings 
excepted}

I found the new Tiger dirs to be amusing. I had to drop my 
GSCacheDirectory and GSDesktopDirectory keys...

IsExecutable and show/hide extensions are pretty trivial NSFileManager 
based on that.

I've also a rev for NSTimeZone which fixes some Win32 strangeness, 
cleans a little code and provides for more flexible packaging but I 
thought this was a little outside of this discussion. Again, it needs 
the Win32 support improvements.

So I was thinking it'd be a reasonably straight-forward commit but there 
is the binary compatibility break we're heading to, which is the right 
time to do this.

> > * Remove PathHandling mode
> >
> > I'm quite concerned about PathHandling mode and want to remove it. I
> > don't think it's necessary and adds more confusion and complexity.
>
> As you know, we had much discussion about path handling, and there was 
> definitely no consensus ... so the current code is a compromise allowing 
> the various viewpoints to be more or less satisfied, and switching of 
> modes during runtime was purely for testing that.  I think the aim is to 
> move to the 'do the right thing' mode once people are generally happy 
> (though perhaps mode control on process startup using an environment 
> variable will be supported).

In my view there should be one and only one mode. Well defined behaviour 
 that can be relied on.

The current behaviour of 'do the right thing' doesn't, in my view, do 
the right thing and gives rise to some quite strange results on win32.

> > * review and recommendations for NSString & NSFileManager
> >
> > I've argued that we don't need Local<->OpenStep conversion generally
> > We also don't need the special ~drive and address@hidden notations. For
> > starters, though I find it bizarre I have come across accounts with user
> > name eg 'a'. Anyway, we don't need the ~ encodings.
> >
> > I'm working on demonstration code to remove these by defining clear path
> > handling semantics which are appropriate for *nix and for win32 without
> > confusing either.
>
> I've already done that ...
> That's why I wanted to know what you were doing :-)

I thought you might have. That's why I issued the invitation to ask ;)

Does this use the current path handling mode semantics?

> > * string optimisations for the Win32 API where buffers are used
> > extensively. Initial testing suggests significant savings are possible 
> > but I want to investigate further.
>
> Sounds good.

Yes and people will be happy that things are faster. I'm not sure 
they'll like delving into the code, though. I'm taking GStr here.


Regards,
Sheldon