[Top][All Lists]
[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