gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnustep-dev] Lessons from a long weekend...


From: richard
Subject: Re: [Gnustep-dev] Lessons from a long weekend...
Date: Tue, 19 Sep 2000 23:44:47 +0100

On Tue, 19 Sep 2000 22:46:55 +0200, address@hidden wrote:
> When trying to rewrite the setString: method on NSText, so that the
> layout manager and the text storage get reused, I found that what
> looked like a very clear solution produced very strange results. The
> text form one field editor was carried over to the next field, when the
> focus moved and the old field was reset to be empty. After hours of
> debugging, searching for some code that changes the cell contents, I
> finally convinced that it is never changed from the outside. So I
> started to think about what was going on and the problem was obvious:
> The text storage and the cell shared the same NSString object!
> The string method of NSTextStorage give back the internal NSString
> object, which gets handed on by the string method of NSText and is
> reused in the setText: method of NSCell. Nobody copies the string as
> this is regarded as producing unnecessary overhead. The solution was
> simple, NSText now returns a copy of the text of its NSTextStorage. But
> this just solves my local problem. We still have this problem all over
> the GNUstep libraries and it will become worse, as soon as programmers
> will start to work with it. The framework is currently not save against
> outside actions. According to the OpenStep specification almost all the
> objects that are put into a public method or returned from a public
> method should be copies of the internal objects. And this is necessary
> so that users of the framework don't have to care too much for its
> internal doings.

Good point -  we should keep an eye open for this problem.
I am not sure that it's as bad/common as you seem to think though.  On the
other hand, it's not just that methods should return copies of ivars,
initialisers and set methods should take copies too.  They shouldn't simply
retain an object if it's mutable and may be changed from somewhere else.

However - it's definately a bug in GSTextStorage that it returns its ivar, so
I've modified it it to return an autoreleased copy, and changed NSText to not
copy the result.

I guess that if it turns out that we *really* need fast access to the ivar
from NSText, we should probably add a hack to use @defs to get direct access
to the internals of the GSTextStorage class.



reply via email to

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