-
Notifications
You must be signed in to change notification settings - Fork 15.3k
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
Objective-C and Any Datatype #1674
Comments
There currently aren't any helpers for it. You can manually inspect the type information to decide if it is a package/message you can support, and then use the bytes in the NSData to call one of the parse methods. |
I already wrote myself an extension in Swift for the GPBAny, which has Is<>() as pall as UnpackFrom(...) and PackTo(...). Would you like me to re-write it in Objective-C and create a pull request? |
Sure, it was something we were hoping to look at doing, just hasn't bubbled up to the top of the queue yet. Adding a category to GPBWellKnownTypes was what we were thinking. |
This is my current swift extension. Maybe you could have a look at it. Let me know your opinion.
|
On quick look, I think the issue is going to the the type names. Since ObjC classes can get prefixes via the file option, the name currently in the descriptor doesn't always line up with what your would be using for type urls. My original thought was we'll likely need to expose some way to provide a registry to map the objc classes to the full type urls to work around it. |
Well, but why can't we use in the objective-c implementation the same logic as in the c/c++ implementation? They are using descriptor->full_name(). |
C++ captures the full proto definition as binary data, that's part of why the code foot print is larger. ObjC's "Descriptors" are just what the runtime needs to function. They don't capture everything the C++ one does. |
Yes, I understand. But I think that parts of it would be sufficient (i.e. full-name). |
Yup, that's the constant balancing act. It would be nice to have it for Any, but for apps with hundreds of protos, the majority likely won't need the data, so it becomes bloat (and it ends up in the armv7 and arm64 segments, so it is duplicated). |
Well, it is a again a valid point, but restricts the usage of protocol buffer more an more. Why can't that be a protoc compiler flag, which would define if the full name is set or not in the generated classes. That would allow the user if the support of Any should work fine or not. |
The catch is cascading protos. If you depend on protos from someone else, they might not generate with the option enabled. Some of the other language Lite runtimes run into similar problems (not having a descriptor). So they are also looking at doing Any support by providing a registry to the calls to provide the mappings. So I was hoping we might be able to end up some what consistent with the other languages in similar situations. |
Okay, but what time frame would that consume to get it done? |
I don't think we have a specific time table. Your extension sounds like it works fine for you for now. But since it relies on the messages not getting prefixed, it wouldn't be a fit for general use in the library. As covered here, there's a few possible ways to deal with it, but the correct decision is clear yet. I'm currently focused on #1457 because it is blocking a few folks from being able to build in general. But I'll try to get some status on the other languages facing this so see if we can reach a consensus and sort out what to do for ObjC. |
Yes, it works fine for me at the moment. I'm already happy if my request would make it on the roadmap 👍 |
Here's the current proposal, hopefully I'll be able to start crank this out this week to get it into a PR.BackgroundC++: https://github.com/google/protobuf/blob/master/src/google/protobuf/any.cc Public API Additions
|
What's the status of this now? |
I've got a draft, but it will cause a incompatibility with the current generated sources, so I've targeted this at 3.1 where that would be allowed. |
- Capture the ObjC prefix used when generating the the file. - Track the containing type on descriptors. - Mark descriptors where the message class name got a suffix added to it. - Expose a fullName property on Descriptors. - Add helpers for packing/unpacking Any messages. - Bump the ObjC runtime version number. Since we added methods and invoke them in the generated code, ensure the code is running against a matching version. Otherwise, someone could compile against headers, but run with a framework that is older and get unknown selector failures. This should trip clearer messaging. Fixes protocolbuffers#1674
I can not find anything about packing and unpacking of Any datatype in objective-c.
Is this implemented and how can I use it?
The text was updated successfully, but these errors were encountered: