You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Sérgio Gomes <sg...@google.com> on 2008/05/29 12:09:47 UTC
Problem when adding support for Polymorphism in ADB C code generator
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.
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Problem when adding support for Polymorphism in ADB C code generator
Posted by Sérgio Gomes <sg...@google.com>.
Hi Dimuthu,
I'll definitely take a look at that; the if blocks sound like a good idea!
Cheers,
Sérgio
---
On Thu, May 29, 2008 at 12:14 PM, Dimuthu Gamage <di...@gmail.com> wrote:
> On Thu, May 29, 2008 at 3:39 PM, Sérgio Gomes <sg...@google.com> 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.
>
> nice to hear you are going through with it:)
>>
>> Say you have a complexType A, which is abstract. Then there are
>> complexTypes A1 and A2, which extend A and are not abstract.
>>
>> 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?
>
> In java, there is a class generated called 'ExtensionMapper' which has
> all the mapping. We can use similar thing to return create and
> deserialize function pointers (may be serialize function pointer as
> well). There you can hard code the mapping inside multiple if blocks,
> rather than using a hash map.
>
> Thanks
> Dimuthu
>
>
>>
>> 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: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Problem when adding support for Polymorphism in ADB C code generator
Posted by Dimuthu Gamage <di...@gmail.com>.
On Thu, May 29, 2008 at 3:39 PM, Sérgio Gomes <sg...@google.com> 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.
nice to hear you are going through with it:)
>
> Say you have a complexType A, which is abstract. Then there are
> complexTypes A1 and A2, which extend A and are not abstract.
>
> 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?
In java, there is a class generated called 'ExtensionMapper' which has
all the mapping. We can use similar thing to return create and
deserialize function pointers (may be serialize function pointer as
well). There you can hard code the mapping inside multiple if blocks,
rather than using a hash map.
Thanks
Dimuthu
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Problem when adding support for Polymorphism in ADB C code generator
Posted by Dimuthu Gamage <di...@gmail.com>.
On Thu, May 29, 2008 at 3:39 PM, Sérgio Gomes <sg...@google.com> 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.
Thanks
Dimuthu
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org