[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSUnarchiver extensions
From: |
Richard Frith-Macdonald |
Subject: |
Re: NSUnarchiver extensions |
Date: |
Tue, 26 Feb 2002 10:29:01 +0000 |
On Tuesday, February 26, 2002, at 10:58 AM, Pierre-Yves Rivaille wrote:
Hello Richard,
As I was trying to add Autoresizing for CustomView in Gorm, I
encountered a problem in maintaining multiple initWithCoder version for
GSCustomView and GormCustomView.
Usually to get the encoded class version you use versionForClassName:,
but in GormCustomView if I call [aCoder versionForClassName: [self
class]], i get an error whenever the class i'm decoding is a
GSCustomView (which is decoded as a GormCustomView because there was a
call to decodeClassName:asClassName:). I haven't found any clean way to
know which real class i'm decoding (a GSCustomView when opening a nib
or a GormCustomView when drag'n'dropping from the palette).
Therefore I have added two new GNUstep specific methods in
NSUnarchiver : +concreteClassNamesForClassName: and
-concreteClassNamesForClassName:, which returns an array of classNames
that are decoded as a specific class.
Before integrating this in gnustep-base, i want to know what is your
opinion on those new methods : will they really bloat the NSUnarchiver
code and should i do a dirty trick in Gorm ? or is it ok to add the two
methods, one ivar and one classvar ?
Unless I'm missing something, I think the change is pointless (and
therefore bloat).
It seems to me that if you are substituting one class for another when
decoding, the replacement class
*must* know all about the class it is replacing.
So the initWithCoder: method of GormCustomView should be calling [aCoder
versionForClassName: @"GSCustomView"]
to get the class version, and should know how to decode an object of the
GSCustomView class of the appropriate
version.
Not only would your suggested additions never be used by any other code,
they are not (as far as I can see)
needed for Gorm either.
Have I misunderstood this?