axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimuthu Gamage" <>
Subject Re: Problem when adding support for Polymorphism in ADB C code generator
Date Fri, 30 May 2008 03:47:54 GMT
On Thu, May 29, 2008 at 3:39 PM, Sérgio Gomes <> wrote:
> Hi everyone,
> I'm developing a patch against the ADB C code generator to allow it to
> handle polymorphism correctly. Let me illustrate my point.
> Say you have a complexType A, which is abstract. Then there are
> complexTypes A1 and A2, which extend A and are not abstract.

Hi Sérgio,

I think we don't need to care whether it is abstract or not. The
polymorphism can occur for any complex type. (that any where complex
content extension goes). So we should not assume it happens only to
abstract types.


> Now, polymorphism can exist in two forms, from the client's perspective:
>  - A parameter in a SOAP method can be of abstract type A; this means
> that you can provide the method with either an A1 or A2 object (not A,
> because it's abstract).
>  - A return value for a SOAP method can be of abstract type A; this
> means that the server will either return an A1 or an A2 (once again,
> not A, because it's abstract).
> The first case is relatively easy to handle, and I've already
> implemented the solution for it. All that is required is for each
> structure to have a pointer to its own serialization method, so that
> even if you cast it to A the right serialization will be performed.
> The second case, however, is quite problematic. The only way to know
> which type is being returned is, of course, during runtime, by looking
> at the xsi:type property. This is relatively easy to do with Axiom,
> but the problem is how to invoke the right create method, but the
> problem is that for this to work correctly, it's necessary to invoke
> the "create" and "deserialize" methods for the right subtype (the ones
> for A won't do, as they aren't aware of the specific properties of A1
> and A2). I thought of creating one global hash table with the
> create/deserialize methods for all types when generating the stub for
> the service, but it doesn't strike me as a particularly elegant
> solution. Does anyone have any other suggestions?
> It's at times like these I wish C had classes and I could just let the
> language handle the issue itself ;-)
> Cheers,
> Sérgio
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message