[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Foundation/...
From: |
Sheldon Gill |
Subject: |
Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Foundation/... |
Date: |
Wed, 16 Mar 2005 13:33:33 +0800 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
Richard Frith-Macdonald wrote:
> On 2005-03-15 08:26:46 +0000 Stefan Urbanek <address@hidden>
wrote:
>
>> Hi,
>>
>> In GSFindNamedFile you use:
>>
>> file_name = [NSString stringWithFormat: @"address@hidden@", aName,
>> anExtension];
>>
>> should not that be rather:
>>
>> file_name = [aName stringByAppendingPathExtension:anExtension];
>
>
> Yes. Thanks.
> I'm still finding oddities in this patch ... and tidying up when I notice
> them.
Actually, no it shouldn't be. At least, not from my design view.
There was a reason I did (A) rather than (B):
GSFindNamedFile is supposed to be called like this:
located_app = GSFindNamedFile( NSStandardApplicationsPaths(),
"MySpecialApp",
"app");
or
icon_for_file = GSFindNamedFile( icon_places,
"TextFile",
"png");
For this sort of use stringByAppendingPathExtension goes through various
steps and calls before hitting stringWithFormat as above so (A) is
faster and incurs less overhead.
The benefit of using (B) means
icon_for_file = GSFindNamedFile( icon_places,
"TextFile/",
"png");
will still find "TextFile.png" where as for (A) it would fail trying to
find ".png" in the "TextFile" sub-directory of each place in the search
paths.
From an API conceptual point of view aName should really be the name of
the file and not a path spec. The pathing is handled already by the
array of places. If you wanted to search in the "TextFile" sub-directory
you'd add it to each element of the path array, *not* the name.
Regards,
Sheldon
{who sometimes has method behind his madness}