Hi Alexey,
With TriComponentId you can achieve the component type, and a field to handle the component instance, but never the name.
So it is really difficult to distinct any component using those fields, specially when components used are defined using the same component type. :)
Anyway, thanks Pavel, Theo & Alexey for your contribution.
Best Regards
Sergio
Mensaje original
De: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Theofanis Vassiliou-Gioles
Enviado el: jueves, 15 de marzo de 2007 14:57
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Re: Component Name
Dear Alexey,
you are right with respect to the ComponentId. At least that was what I
meant ;-) But I was more referring to the *component name*.
But lets take a look at the TRI standard. It says:
> 5.3.1 [...]
> TriComponentIdType A value of type TriComponentIdType includes an identifier, a name and the component
> type. The distinct value of the latter is the component type name as specified in the
> TTCN-3 ATS. This abstract type is mainly used to resolve TRI communication
> operations on TSI ports that have mappings to many test component ports.
Then I have taken a look on the language mapping. (I must admit, I first
looked into the java mapping which says:
> 6.3.2.3 TriComponentIdType
> public interface TriComponentId {
> public String getComponentId();
> public String getComponentName();
> public String getComponentTypeName();
> public TriPortIdList getPortList();
> public boolean equals(TriComponentId port);
> }
> 6.3.2.3.1 Methods
> - getComponentId()
> Returns a representation of this unique component identifier.
> - getComponentName()
> Returns the component name as defined in the TTCN-3 specification. If no name is provided, an empty
> string is returned.
The C mapping says:
> TriComponentId typedef struct TriComponentId
> {
> BinaryString compInst;
> String compName;
> QualifiedName compType;
> } TriComponentId;
which in fact contains the same information.
So, if you are using
compType.create("CompName");
I would assume that this information is included in the compName element
of the TriComponentId. The uniqueness will be guaranteed by the whole
struct (in C) or the object in java.
Best regards,
Theo
Alexey Mednonogov schrieb:
> Ooops, Theo, but no way I can assume that this information is present in
> the TriComponentId as component name, at least as the sole definition of
> component instance reference. At least it shall be prefixed with some
> unique component identification to make sense. The reason is that
> nowhere in the standard it is mentioned to my memory that human-readable
> component name assigned by a test suite writer in the 'create' statement
> has to be unique, while uniqueness is definitely a property of a
> sensible component reference implementation. In fact, the standard does
> not require uniqueness of a human-readable component name explicitly
> (clause 22.1 of Ed. 3). Please correct me if I miss something. Or
> possibly you meant that you do this kind of prefixing already or that
> there is some kind of extension out there.
>
> Best regards,
> Alexey
>
> */Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
>
> While the standard notes, that this information is used for logging
> purposes you can assume that this information is also present in the
> TriComponentId as component name.
>
> If no component name is provided then the componentid will be used
> instead, I assume ;-)
>
>
>
>
