Re: Keyed decoding of geometry

[Richard Frith-Macdonald]

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.

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.

I have absolutely no objection to separating stuff out of large coder 
methods into separate methods for purposes of clarity where appropriate 
... I just think that it would be bad to insist on always separating 
things out in a particular way even where it makes the code less 
readable, especially if dependencies on the policy were built into the 
code so we would have to educate people about it etc.  My personal rule 
of thumb is to never split up a method which can be viewed on one page 
(unless it involves a hideously complex algorithm), and to really think 
about splitting up anything over two pages long.  However circumstances 
alter cases ... and where the structure of the code is very simple (eg 
a method containing nothing by a case statement or a series of 
if,elseif,elseif statements) I don't think splitting the code from each 
statement into a separate method often adds clarity.