Re: Representation Clauses And Freezing

["Marin D. Condic" <mcondic-nospam@acm.com>]

Simon Wright wrote:
> I do agree. But, you are trying to do this with tagged types, and the
> tag part is not specified by the standard.
> 
I understand this. See my other post where I whine and snivel about the
standard not specifying some attribute(s) to enable you to do this. :-)
At least you can get there with some system dependencies, but they'll be
isolated at the lowest level and I generally consider that "fair".

> If you have the same release of the same compiler on the same hardware
> at both ends, why use rep clauses? (I'm assuming that the tag isn't a
> pointer to a type-specific dope structure -- if it was you would be
> completely wrong to try to send such data over the wire or even
> inter-process).
> 
I understand and agree that this is one possibility. However, if you're
building a system that is going to be around for a while and is not for
some very narrow application, you can bet money that you won't have the
same compiler/version/hardware at both ends. You send a message to the
outside world and you don't know what will be at the other end over
time. If your device is useful, someone may want to hook some completely
as yet unknown device to the same wire and want to utilize your message
catalog for as yet unknown purposes. It happens all the time. Either
that, or you're connecting to someone else's message catalog that is
already defined & can't be changed. Hence, you want your message catalog
to be very explicit and detailed because this represents your "contract"
(dare I use that word here? :-) with the outside world.

> If you have any difference at all, you *can not* sensibly send tags
> over the wire.
> 
I don't want to send the tag. I want to strip it out and just send the
data and let the other end figure out what it wants to do with it from
there.

The basic idea here is that if I could build a base class that defined a
message header and all of the low-level services needed to
transmit/receive the messages, I could then very easily extend the base
class for whatever message passing system I have to build and not worry
about the low level details. Key to this is that the low-level
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
basically passing the address of any structure and its size in some TBD
manner and the low level stuff would just send/receive it as bytes. You
can get there with Ada, but you'd prefer to work with what would be the
more "natural" method of tagged records. (I've seen it done in Ada with
addresses, but the code begins to get ugly and doesn't seem to provide
the kind of abstraction that would make it very clean.)

I don't want the derived classes to have to provide similar operations -
just the stuff needed for the content of the extended message. I don't
want the derived class to have to provide conversions to a stream or
anything like that because it shouldn't have to and it only creates
extra programming work (chances for errors, etc) and inefficient message
passing. (Remember, I'm "real-time" here and this is often a critical
issue.)

If the base class can deal with the offset of the tag and can reliably
get the size of the record, then you can handle this fairly well. You
just define an array of bytes and overlay it on the tagged record. You
can then compute the message size and a checksum if needed, fill in
whatever header information you want and blip the stuff down the wire.
It's harder on the way back in, because you are going to have to
recreate the tagged record from a message ID (some version of a case
statement to do your own dispatching, so you'll need knowledge of the
other derived types at that juncture) but there's no way around that one
no matter what you do. Still, the base class can tell you what kind of
message you have from the header and put the bytes into the derived
class once you've determined the record type. Obviously, this is all
dependent on being able to control the representation of all the
messages and not having anything spurious in the record beyond the tag.

If you're curious about it, I've got a paper on my web page that
describes it (originally aimed at being a kind of "training" thing for
the uninitiate - so its kind of basic.)
http://www.mcondic.com/Ada_Programming.html (towards the bottom) There's
also some code to try to illustrate where I'm trying to go. If you look
it over and have suggestions, I'm all ears.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity."

    -- Martin Luther King, Jr
======================================================================