Re: [ccmtools-devel] extended IDL?

[Egon T. <ego...@ut...>]

Hi Darrell!

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!

> 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.

> (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.

:-) Egon