recursive types, struct, custom, dict, etc.

[Havoc Pennington]

On Thu, 2004-06-03 at 21:54, Olivier Andrieu wrote:
>  > as a result the Python bindings could simply throw a VARIANT containing
>  > an int on the wire, and then the caller of GetCount() could perform the
>  > "cast"
> 
> hrmmm, I'd be wary of these implicit casts. Couldn't the python
> binding introspect this ?

The problem is when the object implementation is in python, if the
python user implements a GetCount() method, we're forcing them to also
type in some kind of metadata with the type declaration of said method.

>  - get INT32s and try to cast other variants; but when do you stop
>    converting: INT64? DOUBLE? STRING?

This is a valid question, I guess the simple answer is that only VARIANT
can be converted from (and then only when variant->type ==
expected_type)

INT64 and INT32 are after all distinct types and may not be compatible.
(Though INT32->INT64 is safe, vice versa clearly is not.)

STRING->INT is very evil, since it can fail.

DOUBLE->INT loses information and thus not safe.

> I'd rather see the IDL as a kind of protocol specification that
> everybody is conforming too rather than some optional optimization
> directives for static languages.

Well I think the conversions that will happen have to be well-specified
and mandatory for a given IDL declaration.

> As long as there is a clear API and well defined rules for the
> conversion ...

Right.

>  > Agree we should just do ANY rather than union { int, bool } type of
>  > stuff. i.e. we should do ANY-which-is-one-of-some-set, just keep it
>  > simple. IPC already allows runtime failures, so static type _checking_
>  > doesn't make sense; type checking is inherently dynamic. 
> 
> Aren't contradicting yourself here ? Type checking is what you want to
> do with the separate signatures, no ? ;)

Separate signatures don't add the type checking capability, they just
make it a little bit simpler to implement.

>  > > , and forget about separating type signatures.
>  > 
>  > I'm not sold here. Also, Matthias really wanted to see this.
> 
> even with the variants ?

Yeah his rationale IIRC was being able to implement dispatching as a
quick lookup.

> I don't see where the optimisation would be, compared to what we have
> now. Right now, the signature is built as a message is validated,
> correct ? Is this step of signature building really slow ?

The important optimization with type signatures is for arrays, i.e.
array of int should be:

  typecode ARRAY, typecode INT, LENGTH, VALUE, VALUE, VALUE

not array of variant, like:

  typecode ARRAY, LENGTH, typecode INT, VALUE, typecode INT, VALUE

Similarly for structs, arrays of struct, arrays of arrays, and so forth.
If you have to do separate type signatures for array/struct anyhow, it
seems cleaner to do them always.

Havoc