gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnustep-cvs] r28443 - in /libs/gui/trunk: ChangeLog Source/GSTextSt


From: Fred Kiefer
Subject: Re: [Gnustep-cvs] r28443 - in /libs/gui/trunk: ChangeLog Source/GSTextStorage.m Source/NSTextView.m
Date: Wed, 12 Aug 2009 22:10:53 +0200
User-agent: Thunderbird 2.0.0.22 (X11/20090605)

Richard Frith-Macdonald schrieb:
> 
> On 11 Aug 2009, at 23:19, Fred Kiefer wrote:
> 
>> Fred Kiefer schrieb:
>>>> I did think it was odd that GSTextStorage encoded itself.    The
>>>> question now is, since it does, and, probably has, for a while, I'll
>>>> need to run some tests to see if this is encoded in .gorm files or
>>>> not.  If we simply yank the code it could break compatibility with
>>>> .gorm files created before the change.   I will get back to you with
>>>> results of that test.
>>>
>>> This shouldn't cause any problems as long as we leave the decoding code
>>> in GSTextStorage in place. From then on all text storage objects will be
>>> encoded as NSTextStorage and if there is still one encoded as
>>> GSTextStorage it would still be handled correctly. We could put in a
>>> warning message though, to inform people that the .gorm file will need
>>> to be converted.
>>
>> Oops, perhaps I was a bit too fast here. I had another look at
>> GSTextStorage and this class already implements classForPortCoder and
>> replacementObjectForPortCoder. I think this is wrong and we should
>> remove these as well as the encoding method here, but we definitely
>> should wait for a statement from Richard on this subject as he
>> originally wrote this code and might know best whether it is still
>> needed.
> 
> I have no memory of this, but I would surely have implemented
> classForPortCoder and replacementObjectForPortCoder to ensure that, if
> sent over DO, an object would be copied to the other end (the
> performance impact of using a text storage object via a proxy is
> horrible to contemplate).
> However, I'm sure you are right that it should be NSTextStorage doing
> this, not GSTextStorage.
> 
> So the correct course of action seems to be
> move classForPortCoder and replacementObjectForPortCoder from
> GSTextStorage to NSTextStorage
> remove encodeWithCoder from GSTextStorage (but retain initWithCoder,
> modified to log a warning for backward compatibility)
> implement encodeWithCoder and initWithCoder in NSTextStorage

I am not sure about the moving of classForPortCoder and
replacementObjectForPortCoder. Isn't the default behaviour the correct
one, as soon as we have clasForCoder return NSTextStorage?

Fred




reply via email to

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