Hi Sérgio, See my inline comments.
On Wed, Apr 23, 2008 at 8:02 PM, Sérgio Gomes <[EMAIL PROTECTED]> wrote: > Hi there, > > First of all let me explain what I'm trying to do and what's > happening. I have a method that receives an abstract type A. Of > course, being an abstract type, it's not meant to be instantiated; > there are instead other two types, A1 and A2, which are not abstract, > and inherit from A. > > The problem is, when I provide an object of type A1 or A2 to the > method, I have to cast it to A, and the serialization code will write > it to the XML document as an A, thereby losing all the specific > properties of the derived type and effectively sending an abstract > type as the method parameter. If the serialization code for the > derived type was used instead of the base class's, it would work. The > problem can be generalized to any hierarchy of abstract or concrete > types being passed as parameters or returned as results. > > I can see two solutions to this: one of them is by having each object > contain pointers to the serialization/deserialization functions of its > own type, and using those pointers every time we want to > serialize/deserialize. Yea you are right. Keeping function pointers with the struct is a solution. But I still prefer to use a separate object that return function pointers to a particular adb object, as I proposed earlier. This is because it is not a good practice to keep function pointers in the struct. Although the use case is very rare, when the generated struct grows the backward compatibility breaks. ( axis2/c was having this approach before 0.95 and had to change that as this issue raised) . But for the first trial we may able to work with function pointers in the struct. The other one is by making the objects aware of > their own type and having the superclasse's > serialization/deserialization functions call the appropriate type's > functions (this would likely get quite complex very quickly in > multi-level hierarchies). > > I'm willing to implement these changes myself, but I'd like to hear > some comments regarding the several options and the whole concept. I think this is the super class who need to keep information about it s child. Since the caller only aware of super class type he call it, so the super class need to identify the correct derived type can call logic relevant to that. So this is not an extensible approach in term of Object orientation, (the super class keep information on sub classes). So my suggestion is to work on the first approach. Thanks Dimuthu > > Cheers, > Sérgio > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
