Re: [sv-bc] question about "type mismatch" in section 13 (mailboxes)

Here are some suggested principles to follow in deciding these
kinds of questions:

Consider what the "match" enables.  If its only purpose is to
allow the stored data to be communicated between two scopes
within the application which each need a separate "view" of the
data, then you generally want to equivalent types.

If the match enables one scope to select an access method from
among several candidates to most closely resemble the method
used in the other scope, then you generally want matching types.

Equivalent types offer different ways of viewing information
without changing its abstract meaning.  Matching types insure
that two points of view are functionally identical.

Consider the mailbox mechanism:

If each side in the communication uses a  variable of some type
as a container capable of bearing a message without changing
its meaning, then each side's variable is just its own framework for
interpreting the message contents.  Two endpoints might become
connected "by reference" and this implies that a mapping exists from
one side's frame of reference to the other side's frame.
"Type equivalence" checks that the frame shift is
trivial to implement and preserves meaning.

If, on the other hand, the mailbox mechanism allows sender
and receiver to present a choice of frameworks that might
be applied to interpret the message, only one of which is to
be chosen, then the rule clearly should be "matching types".
Since the sender and receiver thereby seek to insure that they
have adopted the same point of view with respect to the dataset.

Matching helps you choose between two abstractions based on data type.
Equivalence helps you verify that two abstractions are compatible
in the sense that they will preserve the "meaning" of the dataset.

I an not knowledgable about the mailbox mechanism or the intent
of its designers.  But one or the other of the above descriptions
will doubtless seem to be more suitable.

Greg


Francoise Martinolle wrote:
> It is not clear in chapter 13 which describes mailboxes, to which 
> category of type compatibility
> do the mailbox functions get(), try_get() and try_peek() refer to.
>  
> The description states that a runtime error msg occurs if there is a 
> "type mismatch" between the
> message variable and the message in the mailbox.
>  
> I note that the variable is passed by reference and its data type is 
> described as "singular".
> A singular data type is any data type except an unpacked structure, 
> union or array (by the
> way it should also say classes).
>  
> Does the message variable need to have a matching type (5.9.1) with the 
> type of the message in the mailbox?
> or does it need to have an equivalent type (5.9.2)?
> It matters for packed structs, packed unions and packed arrays where the 
> rules are different.
>  
> Francoise
>        '
>  
>  
>  
>  


-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Staff Engineer                                    Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------