The main problem with this is logistical:  By declaring that a protobuf
class should implement a Java interface, you are making protoc-generated
code depend on hand-written, app-specific code.  This means that the build
system must support declaring such dependencies, and that the .proto files
alone cannot be used if you don't have those additional files available.  It
sounds minor, but it leads to a lot of quirky problems.  The feature you're
suggesting would actually be impossible to use with Google's internal build
system, for instance.

Could you instead write wrapper classes which implement the interface in
terms of a particular message type?  For example, if all your message types
share a field "optional int32 id", and you have various code which wants to
operate on arbitrary messages as long as they have an id field.  You could
write:

  interface MessageWithId {
    Message getMessage();
    int getId();
  }

Then for any particular type, you could easily write an implementation of
this interface:

  class FooMessageWithIdAdaptor implements MessageWithId {
    public FooMessageWithIdAdaptor(Foo foo) {
      this.foo = foo;
    }

    public Foo getMessage() { return foo; }
    public int getId() { return foo.getId(); }

    private final Foo foo;
  }

I understand that this is ugly, but allowing generated code to have
arbitrary dependencies is also pretty ugly for other reasons, so we have to
choose the lesser of two evils here.

On Mon, Nov 23, 2009 at 5:09 PM, aantono <a...@antonov.ws> wrote:

> Wanted to hear the community thoughts on adding another option to
> support java_implement_interface.
>
> I think it would be very beneficial to be able to have the protoc
> generate code
> that would be implementing some signature interfaces in the Java
> world.
>
> Unlike Python or Ruby, where if the method exists on an object, you
> can
> call it, in Java the methods must be declared on the classes, so it
> makes
> it difficult to write methods that could take multiple types of
> objects
> which are of Protocol Buffers type without being able to mark them
> with an
> Interface.
>
> I've opened an Issue 59 regarding this change and want to gauge the
> community thoughts on the usefulness of this option.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>
>

--

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@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