Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensions Support #46

Open
sbchisholm opened this issue May 5, 2015 · 4 comments
Open

Extensions Support #46

sbchisholm opened this issue May 5, 2015 · 4 comments

Comments

@sbchisholm
Copy link
Contributor

Any thoughts on how to implement extensions?

@tanmaykm
Copy link
Member

tanmaykm commented May 7, 2015

@sbchisholm, I have encountered extensions rarely and haven't really thought of implementing it yet.
Any suggestions / ideas?

@sbchisholm
Copy link
Contributor Author

For the use case when serializing objects to protobuf, extensions provide a way to mirror the objects in the protobuf message and support inheritance. Here's an example of how it can be accomplished in python:

import message_pb2


class A(object):
  def __init__(self, x, y, z):
    self.x = x
    self.y = y
    self.z = z

  def to_protobuf(self):
    proto = message_pb2.A()
    proto.x = self.x
    proto.y = self.y
    proto.z = self.z
    return proto

class B(A):
  def __init__(self, x, y, z, b):
    super(B, self).__init__(x, y, z)
    self.b = b

  def to_protobuf(self):
    proto = super(B, self).to_protobuf()
    ext = proto.Extensions[message_pb2.b_ext]
    ext.b = b
    return proto
message A{
  required string x = 1;
  required string y = 2;
  required string z = 3;
  extensions 100 to max;
}

message B {
  required string b = 1;
}

extend A {
  optional B b_ext = 101;
}

Extensions in python seem to be supported by the ProtoBuf object using a dictionary indexed by the extension number. I think something similar might work for Julia. We would probably want to have accessors for get_extenstion, set_extension, and has_extension.

@tanmaykm
Copy link
Member

proto3 deprecates Extensions and introduces an Any type which seems simpler.
May be it's better to jump to proto3 instead? Unless there is an immediate requirement.

@sbchisholm
Copy link
Contributor Author

Moving ahead with proto3 sounds like a good plan, Any does look like a much cleaner approach than the Extensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants