PositionableStream>>uint32 etc...??

Michael van der Gulik mikevdg at hetnet.nl
Wed Jul 9 12:21:22 UTC 2003


>   Probably.  This is hard to explain, but if you've got the spec of a
> message packet from someone that looks like:
> 
>   | header <int8> | type <uint16> | nField <uint32> | ...
> 
> and want to fill the packet with some values, I would want to write a
> method look like:
> 
>     fillPacketWithHeader: header type: type nField: nField
>         aStream int8: header.
>         aStream uint16: type.
>         aStream uint32: nField.
> 
> because the method seems to concentrate aStream more on those values,
> and it is easier to see the result conforms the format.
> 
>   You can still say:
> 
>     fillPacketWithHeader: header type: type nField: nField
>         header writeInt8On: aStream.
>         type writeUint16On: aStream.
>         nField writeUint32On: aStream.
> 
> But it at least looks longer^^;

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.

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.

Or maybe:

      fillPacketWithHeader: header type: type nField: nField
          header asInt8    writeOn: aStream.
          type   asUInt16  writeOn: aStream.
          nField asUInt32  writeOn: aStream.

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.

What I eventually want to do is

	aComplexObject writeOn: aStream.

Which requires this approach.

>   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.

If anybody were ever to implement things like a UInt8 class, I suspect 
that it would be much more efficient to implement these at the lowest 
level possible; for a UInt8 you only need a byte (or char in C) whereas 
our trusty SmallInteger is 32 bits. I think - I'm still officially a 
newbie at Smalltalk.

>   Hmm.  I am kind of ok with the current situation.  DataStream
> implements bunch of #writeBlah: so you can take a look at a single
> method category and figure out what it does.

Well, yea. It works. That's step one.

Michael.




More information about the Squeak-dev mailing list