gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread safety/freindlyness vs. performance (Was: Modest string handl


From: David Ayers
Subject: Re: Thread safety/freindlyness vs. performance (Was: Modest string handling optimisations)
Date: Thu, 26 Aug 2004 12:16:00 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707

Richard Frith-Macdonald wrote:

> On 26 Aug 2004, at 10:09, David Ayers wrote:
> 
> 
>> Richard Frith-Macdonald wrote:
>> 
>> 
>>> On 26 Aug 2004, at 01:01, Alexander Malmberg wrote:
>>> 
>>> 
>>>> It also fails if the string is mutable. There are some other
>>>> cases of this in NSString that I've been meaning to fix for a
>>>> while.
>> 
>> ...
>> 
>>> Good point .. I consider this as more of a problem (since the
>>> memory management policy issue is documented and keeps getting
>>> discussed on mailing lists etc).  I guess, while it's not
>>> technically wrong to return a mutable object where a method is
>>> declared as the immutable version (and lots of MacOSX stuff does
>>> it), its more confusing.
>> 
>> ... Yes, this should be fixed.  If the "original" mutable string is
>> altered /after/ the call to -lowercaseString, this must not have an
>> effect on the string returned by -lowercaseString.
> 
> 
> I'm not 100% sure ... there are some methods (eg. 
> stringByExpandingTildeInPath) which are specifically documented as
> returning the receiver, so either we go against the MacOS-X
> documented behaviors in these cases, or we don't have a consistent 
> policy :-( MacOS-X appears to return new objects for lowercaseString
> (for all the strings I tried), but it specifically says it doesn't to
> that for other methods.  I haven't tested, so I don't know whether
> the documentation is telling the truth. Whichever we do, we need to
> document it ourselves, and keep our documentation honest. My
> inclination is to say, in the absence of a general policy, we follow
>  MacOS-X behavior and change things if they change things ... not
> very satisfactory, but it seems pragmatic.

Well... I guess I can see where you're coming from if you consider
GNUstep a drop in replacement for Cocoa, but I think we agree that
that's not what we are and want to be, we do want to be compatible but
not in bug by bug sense.

Now I just went back to read the documentation yet I still consider it a
bug in the design (or documentation /and/ implementation) if a stringBy*
method returns the receiver.  Instead the mutable version could
implement expandTildeInPath.  I would not want to follow Max OS X here.

Cheers,
David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]