On Fri, Feb 3, 2012 at 4:17 PM, Luca Gherardi <luca [dot] gherardi [..] ...> wrote:
>
> Hi all,
>
> I'm working with Hugo for implementing a complex type support in BRIDE.
>
> I defined a metamodel for complex types and a plugin which allow you to define you types library. Now we are trying to define the transformation which should write the property file (.cpf). However we are approaching some problems with the property file which is generated by the marshaling service. Indeed I think that the file we are going to generate has to be conform to the "marshalling file".
>
> I tried to define different kind of properties in a test component and I noticed that not all the simple types are supported.
> See the "table" below (for marshalling result I mean the error which is returned when I try to write the properties on a file ):
>
> type name --- marshalling result --- name of the type in the property file
>
> bool --- OK --- boolean
> vector<bool> --- OK --- bools
>
> char --- char
> unsigned char --- Don't known type unknown_t of unsigned char property and could not convert or decompose it. Dropping it. --- nothing
> vector<char> --- Don't known type unknown_t of vector of char property and could not convert or decompose it. Dropping it. --- nothing
>
> double --- OK --- double
> vector<double> --- OK --- array
>
> float --- Don't known type float of float property and could not convert or decompose it. Dropping it. --- nothing
> vector<float> --- Don't known type unknown_t of vector of float property and could not convert or decompose it. Dropping it. --- nothing
>
> int --- OK --- long
> unsigned int --- OK --- ulong
> vector<int> --- OK --- ints
>
> long --- Don't known type unknown_t of long property and could not convert or decompose it. Dropping it. --- nothing
> unsigned long --- Don't known type unknown_t of unsigned long property and could not convert or decompose it. Dropping it. --- nothing
> vector<long> --- Don't known type unknown_t of vector of long property and could not convert or decompose it. Dropping it. --- nothing
>
> short --- Don't known type unknown_t of short property and could not convert or decompose it. Dropping it. --- nothing
> unsigned short --- Don't known type unknown_t of unsigned short property and could not convert or decompose it. Dropping it. --- nothing
> vector<short> --- Don't known type unknown_t of vector of short property and could not convert or decompose it. Dropping it. --- nothing
>
> string --- OK --- string
> vector<string> --- OK --- strings
>
>
> Here we have the first problems:
> 1) How the type name of the vectors in the property file have been decided? For example vector<double> is called array, which is not really intuitive. Why aren't they called "vector<type_name>"?

It's the typekit which decides upon 'string' names of types. For
historical reasons, the RTT names vector<double> array. Other typekits
may name it differently, which will cause an alias to be installed
such that both names can be used.

> 2) Why a lot of simple types cannot be used? Do I have to define a typekit plugin for them?

Yes. But even so, the XML format's DTD narrows the available types,
not all C++ types can be represented, althought we could allow a
deviation from this since no on else is using/reading this XML format.
So I don't oppose extending the DTD.

> 3) Why float returns a different error with respect to all the others?

I think I added support for floats on the master branch last week.

>
> I also noticed that the name of some types in the property file changes when I define a typekit which contains those types:
>
> vector<bool> becomes "/std/vector</bool>"
> vector<double> becomes "/std/vector</double>"
> vector<int> becomes "/std/vector</int>"
> vector<string> becomes "/std/vector</string>"
>
>
> In my opinion these names are more intuitive. However here comes the second problem.
>
> How we can automatically generate the property file if the name of the same type can be different according to the fact that a typekit was implemented or not? Shouldn't be the name of the property type always the same?

There is no way to fix this. You need to make sure the same typekits
are loaded when reading a certain property file generated with a given
set of typekits in use.

>
> Less important: are "<" and ">" correct or is it a simple coding problem?

Hmm. I think this is an error in the implementation, where > and < are
transcoded, while it's not necessary in quoted attributes... See the
marshalling service's code.

Peter