Thanks for your reply. Indeed i'm using extend now.. it was one of my
possible design, and i was assessing all possible cases.
I have come to this design. And i have a question,  what is
AddExtension for ?

#File AbstractClass

option optimize_for = SPEED;

message AbstractClass
{
        optional int32 AbstractClassInformation = 1;

        extensions 100 to 199;
}


#File ConcreteClass

import "AbstractClass.proto";

message ConcreteClass
{
        required AbstractClass super = 1;

        extend AbstractClass
        {
                optional ConcreteClass derived_ConcreteClass = 100;
        }
}


And using carefully the Extension API, i.e. letting the nested object
or extend part creation to the Extension API, i think
 i managed to obtain a double link between the abstract and concrete
objects.

//test to see field manipulation of Abstract Class from Derived Class
void Test_HD_LinkDerivedToAbstract()
{

        ConcreteClass * cc = new ConcreteClass();
        AbstractClass * ac = cc->mutable_super();

        //42...
        cc->mutable_super()->set_abstractclassinformation(42);

        //yes it does not create another instance
        AbstractClass * ac2 = cc->mutable_super();

        std::cout << "test on link derived to abstract " << endl;
        std::cout << "information from cc instance " << cc->super
().abstractclassinformation() << endl;
        std::cout << "information from ac instance " << ac-
>abstractclassinformation() << endl;
        std::cout << "information from ac2 instance " << ac2-
>abstractclassinformation() << endl;
}

//test to see field manipulation of Derived Class
void Test_HD_LinkAbstractToDerived()
{
        AbstractClass * ac = new AbstractClass();

        //Add extension doesn't seem to work and i dunno why?
        //ac->AddExtension(ConcreteClass::derived_ConcreteClass);
        ConcreteClass * cc = ac->MutableExtension
(ConcreteClass::derived_ConcreteClass);
        cc->mutable_super()->set_abstractclassinformation(42);

        ConcreteClass * cc2 = ac->MutableExtension
(ConcreteClass::derived_ConcreteClass);
        cc2->mutable_super()->set_abstractclassinformation(422);


        std::cout << "test on link abstract to  derived" << endl;
        std::cout << "information from ac instance " << ac-
>abstractclassinformation() << endl;
        std::cout << "information from cc instance " << cc->super
().abstractclassinformation() << endl;
        std::cout << "information from cc2 instance " << cc2->super
().abstractclassinformation() << endl;

        //test ClearExtension OK
        //ac->ClearExtension(ConcreteClass::derived_ConcreteClass);

        //test HasExtension OK
        bool hasExtension = ac->HasExtension
(ConcreteClass::derived_ConcreteClass);
        (hasExtension) ?  std::cout << "well done ;) \n" : std::cout << "T_T
have to change your design\n";
}

This current design kind of satisfying me, i will try to test it in
the Java generated Classes :) .

cheers,

Pascal Ly.


On May 28, 8:44 pm, Kenton Varda <ken...@google.com> wrote:
> You can only have mutually-recursive messages if they are defined in the
> same file.
>
> I don't think your approach would work quite as you expect anyway.  Message
> fields are not pointers, so you can't have a recursive object at runtime.
> That is, if you do:
>
>   message A {
>     optional B b = 1;
>   }
>   message B {
>     optional A a = 1;
>   }
>
> If you have an instance of A called foo, you *cannot* make it so that
> foo.b.a == foo -- foo.b.a is an entirely different object.
>
> If you need to be able to down-cast (that is, given a pointer to the
> superclass, you need a way to get a pointer to the subclass), then you need
> the superclass to look like:
>
>   message Superclass {
>     // One of the following will be filled in.
>     optional Subclass1 subclass1 = 1;
>     optional Subclass2 subclass2 = 2;
>     ...
>   }
>
> You can use extensions instead of normal fields, which is often useful for
> these cases.  Other than that, though, there's no other option.  You cannot
> convert a Subclass1 back to a Superclass, so you have to pass around
> pointers to the Superclass itself and simply say "This object must contain a
> subclass1".
>
> In general, you may find that trying to shoe-horn a concept of inheritance
> into protocol buffers doesn't work well.  Unfortunately, classic
> object-oriented inheritance does not translate well to message formats sent
> over the wire.  Extensions, on the other hand, are very straightforward on
> the wire, which is why that is what protocol buffers provides.
>
>
>
> On Thu, May 28, 2009 at 10:16 AM, <ly.pas...@gmail.com> wrote:
>
> > Just to complete the view, i' m trying to simulate inheritance.
>
> > Derived Classes need to have a required field to their mother (so that
> > when i'm using directly a derived class i can set the super class
> > fields).
>
> > And abstract classes need to have an optional field
> > to all possible derived classes (emulate the fact that a super class
> > can become any sort of derived class).
>
> > I can bypass the problem by using "extend" in the derived classes
> > message file (extending field of the super class, adding an optional
> > field of themselves) , so that only the derived classes side need to
> > use import.
>
> > but i was wondering if there was another way to do so ??
>
> > cheers,
>
> > Pascal ly
>
> > On May 28, 6:51 pm, ly.pas...@gmail.com wrote:
> > > Hi,
>
> > >  i need a message A to have a field with a message B, and at the same
> > > time i need messages B to have a field to message A, how to avoid
> > > recursive imports ??
>
> > > cheers,
>
> > > Pascal Ly.- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to