Re: Representation Clauses And Freezing

[tmoran@bix.com]

>operations are class-wide. No matter how you extend the message, the
>base class needs to be able to determine where the "real" data is in the
>record, how big it is, how to checksum it, how to interpret it as raw
>bytes, etc, etc. In a weakly typed language, you could do this by

You can really do a lot with Streams.  You can of course define a
'Write to one child of Root_Stream_Type that puts the bytes of the
data object into a Stream_Element_Array.  But a different child of
Root_Stream_Type could instead put a kind_of_record_indicator, or a
checksum, or a length, or even an address into its resulting
Stream_Element_Array.  So your Output_To_Device procedure could take
a Stream_Element_Array that consisted of one (or more) triples of
(count, checksum, start_address), should you want to do that.
  For bitmaps In Claw we use record rep clauses (with TAG_SIZE
offsets included) to lay things out for Windows system calls, but we
define Mono_Bitmap'Class'Read, VGA_Bitmap'Class'Read, etc, for use in
embedding bitmaps in files or sending them over networks.  That's also
used internally for the
  function Read(Filename:String) return Claw.Root_Bitmap'Class;
kind of thing for simple read/write of .bmp files.