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
|