Re: Rep clause problems, was Re: S'Write and How To Count Bytes

[Simon Wright <simon@pogner.demon.co.uk>]

Marin David Condic <mcondic.nospam@acm.org> writes:

> So with my technique, you could avoid the whole mess just so long as
> you could absolutely control the representation of a tagged
> record. Various suggestions have been made to, for example, put a
> well-rep'd record inside the tagged record, but this has problems
> with not allowing class-wide operations to be built. You've got to
> build a new set of operations for each new type in the class. Yeah,
> you can do it, but then you're defeating the elegance of the
> solution and forcing a lot of work on building the descendent
> types. Also, its tough to come up with good ways of doing things
> like checksumming the records and other things that rely on looking
> at the whole thing as a unit.

I thought you had predefined message formats, which have to be
understood by code over which you have little control. So this format
will specify field locations and (if you're lucky) endianness. What it
certainly won't contain is a space for an Ada tag.

Seems to me you need packages to handle the wire formats and packages
to handle your tagged types; and when it comes to send a message you
might use streams in your tagged type package, but the implementation
of the 'Output etc will need to use the appropriate wire format
package. And the input wire format package will create and return some
object(s) in your tagged world.

I'm assuming that your tagged types are in your application domain,
not the comms domain? if the former, I've found that messages rarely
map at all to application classes; if the latter, the message set
rarely maps straightforwardly to any sort of inheritance tree.