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 "Lefrancois, Carl" <Ca...@axa-canada.com> on 2008/05/30 17:03:06 UTC
Discussion: adding support for Polymorphism in ADB C code generator
>Now, these "global" functions would know all the types, and would be
able to call the appropriate *_impl functions for them. For
serialization to work, we need to store the type name in every
structure, per Carl's suggestion. For deserialization to work, we would
need to check the type name (xsi:Type) in the node.
>So, in terms of code, this would be, as suggested:
>struct adbType
>{
>axis2_char_t property_Type[64];
>}
Actually it is Dimuthu's idea, but it was my fault to suggest a 64 item
array. It should really be
struct adbType
{
axis2_char_t *property_Type;
}
And in the _create:
_type->property_Type = (axis2_char_t *)AXIS2_MALLOC(env->allocator,
sizeof(axis2_char_t) * axutil_strlen("<type name>");
strcpy(_type->property_Type, "<type name>");
In my project there is already a type name that is 50 characters long so
I would not be comfortable having any limit on type name in a code
generator.
>>So, the global serialization function could be:
axiom_node_t* AXIS2_CALL
adb_serialize(
adbType_t* _element,
const axutil_env_t *env, axiom_node_t *parent,
axiom_element_t *parent_element, int parent_tag_closed, axutil_hash_t
*namespaces, int *next_ns_index) {
if (strcmp(struct->property_Type, "adb_A") == 0) {
return adb_A_serialize_impl((adb_A_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
if (strcmp(struct->property_Type, "adb_A1") == 0) {
return adb_A1_serialize_impl((adb_A1_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
...
}
In the example above, I don't understand the adbType_t* used for the
_element parameter. Also, where is struct-> defined? Dimuthu's
suggestion of having a char pointer as the first element of the struct
for each sub-type allows a pointer to any sub-type object to be cast to
char *.
It seems better to use void * for the element parameter of the global
adb_serialize function. A modified version of your global serialization
function:
axiom_node_t* AXIS2_CALL
adb_serialize(
void *_element,
const axutil_env_t *env, axiom_node_t *parent,
axiom_element_t *parent_element, int parent_tag_closed, axutil_hash_t
*namespaces, int *next_ns_index) {
if (strcmp((char *)_element, "adb_A") == 0) {
return adb_A_serialize_impl((adb_A_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
if (strcmp((char *)_element, "adb_A1") == 0) {
return adb_A1_serialize_impl((adb_A1_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
...
}
>Neither of these would assure that you could only instance objects of
the specific type hierarchy you're expecting, however. Where would this
get done, and does it matter if it isn't?
You're right about the lack of parent hierarchy enforcement. You could
always add parent type information too, maybe using ';' so separate the
type names in the property_Type element of sub-type structures. I
believe Dimuthu said that the code generation engine provides parent
type information at the sub-type level.
In other words:
Adb_A1_create(..)
{
..
Strcpy(_adb_A1->property_Type, "adb_A1;adb_A"); // or
"adb_A1;adb_A;adb_parent_of_A" etc.
..
}
Then take the first token parsed out of this list when doing stricmp of
type information during serialization / deserialization.
The question then becomes is it worth this extra effort to implement
these checks? I don't believe it is, since the resulting XML document
should be validated by the server anyway.
Thoughts?
Carl
_____
"Ce message est confidentiel, a l'usage exclusif du destinataire
ci-dessus et son contenu ne represente en aucun cas un engagement de la
part de AXA, sauf en cas de stipulation expresse et par ecrit de la part
de AXA. Toute publication, utilisation ou diffusion, meme partielle,
doit etre autorisee prealablement. Si vous n'etes pas destinataire de ce
message, merci d'en avertir immediatement l'expediteur."
"This e-mail message is confidential, for the exclusive use of the
addressee and its contents shall not constitute a commitment by AXA,
except as otherwise specifically provided in writing by AXA. Any
unauthorized disclosure, use or dissemination, either whole or partial,
is prohibited. If you are not the intended recipient of the message,
please notify the sender immediately."
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Discussion: adding support for Polymorphism in ADB C code generator
Posted by Dimuthu Gamage <di...@gmail.com>.
On Fri, May 30, 2008 at 8:33 PM, Lefrancois, Carl
<Ca...@axa-canada.com> wrote:
>
>>Now, these "global" functions would know all the types, and would be
> able to call the appropriate *_impl functions for them. For
> serialization to work, we need to store the type name in every
> structure, per Carl's suggestion. For deserialization to work, we would
> need to check the type name (xsi:Type) in the node.
>
>>So, in terms of code, this would be, as suggested:
>
>>struct adbType
>>{
>>axis2_char_t property_Type[64];
>>}
>
> Actually it is Dimuthu's idea, but it was my fault to suggest a 64 item
> array. It should really be
>
> struct adbType
> {
> axis2_char_t *property_Type;
> }
>
> And in the _create:
>
> _type->property_Type = (axis2_char_t *)AXIS2_MALLOC(env->allocator,
> sizeof(axis2_char_t) * axutil_strlen("<type name>");
> strcpy(_type->property_Type, "<type name>");
>
> In my project there is already a type name that is 50 characters long so
> I would not be comfortable having any limit on type name in a code
> generator.
>
+1
>
>
>
>>>So, the global serialization function could be:
>
> axiom_node_t* AXIS2_CALL
> adb_serialize(
> adbType_t* _element,
> const axutil_env_t *env, axiom_node_t *parent,
> axiom_element_t *parent_element, int parent_tag_closed, axutil_hash_t
> *namespaces, int *next_ns_index) {
> if (strcmp(struct->property_Type, "adb_A") == 0) {
> return adb_A_serialize_impl((adb_A_t *)_element,
> env, parent, parent_element, parent_tag_closed,
> namespaces, next_ns_index);
> }
>
> if (strcmp(struct->property_Type, "adb_A1") == 0) {
> return adb_A1_serialize_impl((adb_A1_t *)_element,
> env, parent, parent_element, parent_tag_closed,
> namespaces, next_ns_index);
> }
> ...
> }
>
>
> In the example above, I don't understand the adbType_t* used for the
> _element parameter. Also, where is struct-> defined? Dimuthu's
> suggestion of having a char pointer as the first element of the struct
> for each sub-type allows a pointer to any sub-type object to be cast to
> char *.
That' s just remove one redirection (avoids ->). anyway that s
negligible. And may be add some readability.
>
> It seems better to use void * for the element parameter of the global
> adb_serialize function. A modified version of your global serialization
> function:
>
> axiom_node_t* AXIS2_CALL
> adb_serialize(
> void *_element,
> const axutil_env_t *env, axiom_node_t *parent,
> axiom_element_t *parent_element, int parent_tag_closed, axutil_hash_t
> *namespaces, int *next_ns_index) {
> if (strcmp((char *)_element, "adb_A") == 0) {
> return adb_A_serialize_impl((adb_A_t *)_element,
> env, parent, parent_element, parent_tag_closed,
> namespaces, next_ns_index);
> }
>
> if (strcmp((char *)_element, "adb_A1") == 0) {
> return adb_A1_serialize_impl((adb_A1_t *)_element,
> env, parent, parent_element, parent_tag_closed,
> namespaces, next_ns_index);
> }
> ...
> }
>
>
>
>>Neither of these would assure that you could only instance objects of
> the specific type hierarchy you're expecting, however. Where would this
> get done, and does it matter if it isn't?
>
> You're right about the lack of parent hierarchy enforcement. You could
> always add parent type information too, maybe using ';' so separate the
> type names in the property_Type element of sub-type structures. I
> believe Dimuthu said that the code generation engine provides parent
> type information at the sub-type level.
>
> In other words:
>
> Adb_A1_create(..)
> {
> ..
> Strcpy(_adb_A1->property_Type, "adb_A1;adb_A"); // or
> "adb_A1;adb_A;adb_parent_of_A" etc.
> ..
> }
>
> Then take the first token parsed out of this list when doing stricmp of
> type information during serialization / deserialization.
>
> The question then becomes is it worth this extra effort to implement
> these checks? I don't believe it is, since the resulting XML document
> should be validated by the server anyway.
Yea. It doesn't worth that much of an effort. Since most of the time
the current implementation do the work. And as I suggested if we keep
traditional getters/setters users may need not to aware about the type
hierarchy. And in cases it use (where complexContent extension
present), it is acceptable the developer need to go through the wsdl
and identify the type hierarchy himself.
Dimuthu
>
> Thoughts?
>
>
> Carl
> _____
>
> "Ce message est confidentiel, a l'usage exclusif du destinataire
> ci-dessus et son contenu ne represente en aucun cas un engagement de la
> part de AXA, sauf en cas de stipulation expresse et par ecrit de la part
> de AXA. Toute publication, utilisation ou diffusion, meme partielle,
> doit etre autorisee prealablement. Si vous n'etes pas destinataire de ce
> message, merci d'en avertir immediatement l'expediteur."
>
> "This e-mail message is confidential, for the exclusive use of the
> addressee and its contents shall not constitute a commitment by AXA,
> except as otherwise specifically provided in writing by AXA. Any
> unauthorized disclosure, use or dissemination, either whole or partial,
> is prohibited. If you are not the intended recipient of the message,
> please notify the sender immediately."
>
> ---------------------------------------------------------------------
> 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