Re: Keyed decoding of geometry

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> On 26 Jan 2004, at 01:06, Fred Kiefer wrote:
>
> > Richard Frith-Macdonald wrote:
> >
> > > On 24 Jan 2004, at 17:06, Fred Kiefer wrote:
> > >
> > > > And I also tried to write a few sample decoding methods based on 
> > > > that NIB file. I made specific methods out of them, so that it will 
> > > > be easier to keep them a bit apart from our current decoding code. 
> > > > Actually I would like to see some method like the follwoing on 
> > > > NSObject so we dont have to mix the different code in one method:
> > > >
> > > >
> > > > - (id) initWithCoder: (NSCoder*)aCoder
> > > > {
> > > >   if ([aCoder allowsKeyedCoding])
> > > >     {
> > > >     self = [self initWithKeyedCoder: aCoder];
> > > >     }
> > > >     else
> > > >     {
> > > >     // call old decoder code, for which I don't have a great name
> > > >     }
> > > > }
> > >
> > > Maybe, on the other hand, keeping the two together might be 
> > > considered a virtue ... certainly if the code involved is small.
> >
> > We should try to get more opinions on this. The pros for a separate 
> > hierarxchy for each encoder type arethat the methods are shorter and 
> > cleaner and that calls to super may use the short cut, as they know 
> > what sort of archiver they are dealing with. For the cons I only see 
> > the additional method call.
>
>
> Ah ... I see things a bit differently ...
>
> For many (most?) classes, encoding/decoding is a trivial matter of a few 
> ivars and a call to the superclass method.  In these cases, keeping a 
> single method keeps the whole thing together so you can see the whole 
> thing at once ... so it's clearer and simpler.  Splitting into separate 
> methods only enhances clarity where coding/decoding is large and 
> complex, and sometimes even then a simplistic split would make the code 
> less maintainable, for instance if the amount of data encoded was small 
> but the setup code based on that data was large, a threeway split would 
> make more sense, with two methods for keyed/nonkeyed decoding and a 
> third method to set up the object state based on the data decoded.

Looks like we have a disagreement here. What about a compromise for the 
time this area is still under heavy development? For now the keyed 
unarchiving code goes into a separate method that gets called from the 
specific initWithCode: methods that still contain the old decoder code. 
When we are sure about the code that goes there we can see, if there is 
any similarity with standard coding making sharing worthwhile, or not.

At least for the AppKit classes this will be needed. I am not that sure 
about the Fondation classes. Here the few classes I did implement are so 
simple, that merging the code would do. So what about doing Foundation 
your way (everything in one initWithCoder: method) and AppKit uses the 
separate method approach, with a review taking place in about half a year?

If this is fine for everybody I would apply preliminary code for keyed 
decoding (I am not interested in encoding, whoever needs this will have 
to write his/her own code) today.

> Using calls to super of initWithKeyedCoder: looks dubious to me, as it
> would only save a single method call as far as performance goes, but
> would make the code less maintainable ... for instance, if someone
> removes an initWithKeyedCoder: implementation in the middle of the
> hierarchy (something someone not knowing about the policy might do if
> they look at the code and want to simplify it) they would break  the
> coding of classes lower in the hierarchy.  Much better to stick to the
> documented/standard behavior and call the normal superclass methods.
>

The same would be true for most other changes to intermediate decoding 
methods. But no need to argue here, as we will review this later on.