Types name in properties file

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>"?
2) Why a lot of simple types cannot be used? Do I have to define a typekit plugin for them?
3) Why float returns a different error with respect to all the others?

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?

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

Thanks,
Luca

------------------------------------------------------------------------------

Luca Gherardi
PhD Student at University of Bergamo
Dept. of Information Technology and Mathematics
V.le Marconi, 5 - 24044 Dalmine, Italy
Tel +39 333 8396279
Home: http://www.lucagherardi.it

Types name in properties file

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