Re: NSUnarchiver extensions

[Richard Frith-Macdonald]

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?