Hello,
This is a good question!
Unfortunately, the standard leaves the answer to it wide open:
The BNF explicitly allows InlineTemplate in the FromClause, so
syntactically any matching mechanism could be allowed here.
The table restricting matching mechanisms does not mention component
types (also not default types) so it is unclear if the table simply does
not restrict matching mechanisms for this type or if it does not
explicitly allow any for component types. Since the standard normally
forbids something by explicitly restricting it, and taking the BNF into
account, I would assume that matching mechanisms for component types
should be allowed. Of course, only Instead-of-Value matching mechanisms
make sense here.
Since the special value 'null' seems to be present in any component
type, the template MyCompType:? should also match for 'null'. But, as
you have correctly pointed out, since the sender never can be 'null',
this is a non-issue in case of the FromClause. Explicitly using
MyCompType:null would simply be a case of an alternative which can never
match (which cannot be avoided in general anyway) - it would be like
disallowing if (false) { ... }. It is more a tool-issue how the tool
deals with such situations.
The example in the standard is either simply a bit confusing (if one
assumes that the component variables have been assigned some specific
component references before entering the alt-statement) or simply wrong
or non-sensical (if the variables still contain the null-value). In the
first case, it does, of course not really make sense to assign the
sender to the same variable as is used in the FromClause as that would
always change nothing.
So, answering your question I would say, in my opinion, the standard
could be interpreted like this:
a) it is legal, but will cause an alternative which will never match
b) inserting MyCompType:? is legal and will match any sender component
of type MyCompType. For consistency's sake, subtypes of MyCompType are
probably forbidden as matching in receive-statements normally demands
strong typing. However, I also don't see any harm to allow all component
types compatible to MyCompType here.
In general, I think the standard is a bit vague in that respect and
should probably be clarified. Also, the example should be re-designed.
BR, Jacob Wieland
--
Dr. Jacob Wieland
Software Engineer
Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany
Phone +49 30 726 19 19 34 Email
This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com
Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.