From 0e047663cf192010f39aa3129c85b686293eccd2 Mon Sep 17 00:00:00 2001 From: Richard Kistruck Date: Mon, 24 Nov 2008 16:20:35 +0000 Subject: [PATCH] Mps br/timing: design/message: Write new .class.type: each class now implements exactly one type. .class.not-type is now false; mark it as obsolete. Copied from Perforce Change: 166796 ServerID: perforce.ravenbrook.com --- mps/design/message/index.html | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/mps/design/message/index.html b/mps/design/message/index.html index 389707a0d0e..2c01e195225 100644 --- a/mps/design/message/index.html +++ b/mps/design/message/index.html @@ -152,7 +152,7 @@

Support lifecycle, by distinguishing between unsent and received states

-

Choose one state -- unsent for example -- and distinguish it by defining that the RingStruct queueRing is set to NULL in that state. Need to check that this would actually help the only current re-user of Messages: TraceStart.

+

Choose one of these states -- unsent for example -- and distinguish it by defining that the RingStruct queueRing is set to NULL in that state. Need to check that this would actually help the only current re-user of Messages: TraceStart.

@@ -353,6 +353,19 @@ MessageClassStruct (a struct). Clients of the Message module are expected to allocate storage for and initialise the MessageClassStruct. It is expected that such storage will be allocated and initialised statically. +.class.type: Each message class implements exactly one message type. +The identifier for this type is stored in the "type" field of the +MessageClassStruct. Note that the converse is not true: a single +message type may be implemented by two (or more) different message +classes (for example: for two pool classes that require different +implementations of that message type). + +BEGIN OBSOLETE SECTION "class-not-type". +[.class.not-type.not: It used to be the case that message classes and message +types were completely distinct. This was never used and was unnecessary. It +was removed by making message-type an attribute of the implementing +message-class, ie. moving the type field out of MessageStruct and into +MessageClassStruct. RHSK 2008-11-24.] .class.not-type: Note that message classes and message types are distinct. .class.not-type.why: (see also mail.drj.1997-07-15.10-33(0) from which this is derived) This allows two different implementations (ie classes) of messages @@ -361,6 +374,7 @@ management of the messages may be different in the two implemtations (which is bogus). The case of having one class implement two types is not expected to be so useful. .class.not-type.why.not: It's all pretty feeble justification anyway. +END OBSOLETE SECTION "class-not-type" .class.methods.generic: The generic methods are: