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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
