Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]

[Richard Frith-Macdonald]

On 2005-05-10 01:07:00 +0100 Sheldon Gill <address@hidden> wrote:

> > > 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.

> Still progressing
>
> * Path handling fixes in the rest of base and gui: where we have
>   assumptions about layout which are no longer valid or where
>   the code can be cleaned up
>
> * More and better use of Unicode and Win32 api. We should be
>   using either Step or native methods as far as possible to
>   improve behaviour. This will be ongoing for a while...
>
> * Framework support on win32. With my _find_framework() in NSBundle we
>   can now properly locate the framework directory and so know exactly
>   where the DLL is. We can load it explicitly when needed.
>   Its a case now of linking and symbol resolution.
>   A ways off (because of time)

Please could you submit individual patches for each of these dozen or more 
changes?
If we get individual patches over a space of time as they are developed, we 
can integrate them into GNUstep promptly ... which is definitely not the 
case if we get a few large patches at once.  Larger and more complex patches 
take a long time to review, and have to wait for people to have that time 
available ... which can mean that improvements which could have been 
immediate take many months (perhaps so long that they become 
irrelevant/unusable) to become available.

> * 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).

> Currently, it's a global variable. The mode could be changed by a
> loadable bundle without the application code being aware of it.
> Hence, code can be expecting to run in one mode and be invoked when it's
> different.
> Further, it could be changed in one thread and mess up the processing in
> a different thread which happens to be executing at that time.

It's a non-issue, switching is there for testing purposes and real programs 
don't do it.
Once we are out of testing, programmatic switching of modes can be removed 
(unless people want to keep it for some reason).

> * 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 :-)

> * 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.