Michael,

> >     fillPacketWithHeader: header type: type nField: nField
> >         aStream int8: header.
> >         aStream uint16: type.
> >         aStream uint32: nField.
> > 
> >     fillPacketWithHeader: header type: type nField: nField
> >         header writeInt8On: aStream.
> >         type writeUint16On: aStream.
> >         nField writeUint32On: aStream.
> > 
> I think it's much of a muchness - I don't personally see one being 
> tidier than the other. The first is just the same as the second, except 
> that the message and receiver are switched.

  Ah, yes.  But when I look at the first, in my brain, I can see the
schematic picture of packet format is getting filled with those
values.  I don't feel it in that way in the second.

> The second could also be written as:
> 
>       fillPacketWithHeader: header type: type nField: nField
>           header writeOn: aStream.
>           type   writeOn: aStream.
>           nField writeOn: aStream.
> 
> Assuming that header is of class Int8, type is of class UInt16... etc. 
> This would be more "OO", but unfortunately these classes don't exist.

  I see...  I guess the problem is that we don't know if we want to
have those different classes.

> I think that my biggest argument is that the whole idea of 
> object-orientation is encapsulation - only the ULongDoubleFloat96 class 
> (or whatever) should know what it's internal representation is and 
> therefore should be responsible for representing itself as a stream of 
> bytes.

  I respect this argument.  However,

> What I eventually want to do is
> 
> 	aComplexObject writeOn: aStream.
> 
> Which requires this approach.

  the same argument could be applied to aStream.  DataStream and its
subclasses have several instance variables, and when a objects in a
reference graph is being written, DataStream's inst var have to be
accessed from the logic.  ComplexObject>>writeOn: cannot do it without
breaking some principle.

  One could say that serialization is meta-enough so it can break the
principle.  If so, we might want to concentrate those rule breakers at
one place; namely a class hierachy starting at DataStream.

> >   I don't know about making them primitives...  Why do you want them
> > be primitives?
> 
> I don't. But the author of Magma used primitives to do this for speed 
> reasons.

  I'm a bit curious how much speed gain one can get.  I would imagine
that unless writing an array or something, it doesn't give us too much...

-- Yoshiki