Re: [ccmtools-devel] extended IDL?

[Darrell S. <da...@sc...>]

Hi Egon,

On Jun 7, 2005, at 4:03 PM, Egon Teiniker wrote:
>
> Darrell Schiebel wrote:
>
>> After a lot of work with ccmtools over the past few weeks (I have the
>> python binding generator working for ccmtools' basic example, but I
>> need to get it in a shape to hand back to Egon),
>>
>
> Hey, this sounds great!

The python version of the test/tutorial is below. I set it up so that  
the component homes are automatically created, but in thinking about  
it, I think perhaps the user should start with the home-finder. This  
would allow (at some point) remote and local components to be mixed  
easier. Do you agree?
>
>
>> I'm left wondering
>> what to do if we really want the local interface to have data
>> structures which are not representable in IDL. In our case, it is
>> dictionaries (something like dictionary<key_type,val_type>. It seems
>> like there are a few options:
>>
>> (1) extend IDL (or use XML) to represent the interface and then  
>> use  the
>> generators (local & target) to narrow & expand the extra type,  e.g.
>> convert the dictionary to XML or a multidimensional array to  shape +
>> vector
>>
>
> Extending IDL's syntax seemed to be a tough task including changes in
> IDL3 parser, CCM metamodel library and generator backends too.

That makes sense...

>
>> (2) augment IDL with an XML database which tells that some subset of
>> the parameters, e.g. shape + vector, are REALLY a multidimensional
>> array so the generated user code (at both ends) should reconstitute a
>> multidimensional array and not a pair of vectors
>>
>
> Using XML (or another language) that can be represented in IDL as a
> simple string is straight forward, but does not support a type- 
> check at
> compile-time  - (I know, this is not the right argument for Python
> programmers ;-).
>
>
>> (3) hammer the interface down until it really can be represented  
>> in  IDL
>> even if we don't want to
>>
>
> Yes we have already used this approach to define an exception stack  
> trace:
>
> struct ErrorInfo
> {
>   long code;
>   string message;
> };
>
> typedef sequence<ErrorInfo>  ErrorInfoList;
>
> exception Error
> {
>   ErrorInfoList list;
> };
>
>
>
>> Right now it seems like (1) or (3) are the best options. Does anyone
>> else have any opinions about this? This seems like it would be a very
>> nice thing for CCMTOOLS to support, i.e. expanding the basic IDL
>> interface with non-native types and then allow specification on how
>> these map to IDL and back again.
>>
>
> Currently, we are planning to use the IDL any mechanism to pass  
> dynamic
> data structures as method parameters. In that case we have to options:
>
> a) We define a default mapping from IDL any to dynamic C++ structures
> (here we can use the WX::Utils::value* classes provided by the
> cpp-environment).
>
> b) We allow the developer to define its own set of IDL any to C++
> converter which can be hooked in at generation time (e.g. an XML file
> contains the converter signatures which can be used by the ccmtools
> generators).
>
> IDL any does not support type checking at compile time, but with an
> appropriate mapping to C++ we do not have to pay the XML parsing
> overhead in the local case - we can pass C++ references to dynamic C++
> structures.

The "any" with generated to/from mappings in the generated code makes  
a lot of sense, thanks Egon. We'll probably do that to transport  
heterogeneous dictionaries as well as multi-dimensional arrays.  
Before too long I'll have to create RPMs so that others can use my  
python generator. At that point, I'll send you a copy and try to help  
clean up any unnecessary deviation from the current state of the CVS  
repository.

Darrell