PHP custom options not available

[camuthig]

Is there any way currently access custom option values using the generated PHP classes? It seems like when I add one to my proto file then my generated class lists having an UninterpretedOption however I currently see two problems:

1. The descriptor is private and there is no getter on the Message class
2. The value of the option isn't saved anywhere that I can find

Are there plans to support this feature for PHP?

[TeBoring]

Sorry that we don't support it currently. But it's on our plan. On Fri, May 5, 2017 at 14:21 Chris Muthig [email protected] wrote:

Is there any way currently access custom option values using the generated PHP classes? It seems like when I add one to my proto file then my generated class lists having an UninterpretedOption however I currently see two problems:

1. The descriptor is private and there is no getter on the Message class
2. The value of the option isn't saved anywhere that I can find

Are there plans to support this feature for PHP?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/protobuf/issues/3065, or mute the thread https://github.com/notifications/unsubscribe-auth/AE9H5fytWxB5l_poIX5Qv2rfcbwDS6Nmks5r25LpgaJpZM4NSb-7 .

[camuthig]

@TeBoring do you have any timeline for the functionality?

[TeBoring]

Probably end of this quarter. On Fri, May 5, 2017 at 15:43 Chris Muthig [email protected] wrote:

@TeBoring https://github.com/TeBoring do you have any timeline for the functionality?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/google/protobuf/issues/3065#issuecomment-299592165, or mute the thread https://github.com/notifications/unsubscribe-auth/AE9H5VWK8m4p-reJ_mOLO1s4DsT6tyAsks5r26YfgaJpZM4NSb-7 .

[francislavoie]

Any chance this will be added in the near future? I'd like to use EnumValueOptions to associate a couple extra string fields with my enum.

[TeBoring]

I don't have time for this feature now. Maybe early next year. On Wed, Nov 8, 2017 at 06:55 Francis Lavoie [email protected] wrote:

Any chance this will be added in the near future? I'd like to use EnumValueOptions to associate a couple extra string fields with my enum.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/google/protobuf/issues/3065#issuecomment-342841803, or mute the thread https://github.com/notifications/unsubscribe-auth/AE9H5Zv10dYZja5JQ2EW46_IkuuM4g0Iks5s0cDqgaJpZM4NSb-7 .

[phphphphphp]

What is the status of this ticket? Is this on any roadmap, or is there any work in progress to implement this? Being able to use custom options in PHP would be huge for my team's use case, however it seems this ticket hasn't seen activity for almost 3 years now.

[haberman]

I think PHP support for custom options should be achievable within the next six months.

upb (the C library underlying PHP's extension) will soon be getting support for extensions, which is the last major hurdle to supporting custom options.

[esorot]

Update: This is now supported in upb. We would need to prioritize creating the glue code to make it work.

[calvin2021y]

@haberman @esorot

any update?

[haberman]

Custom options are supported in the "upb" C library that underlies that PECL extension, so all external blockers are removed.

But there are several things that would need to be implemented at the PHP layer to offer this feature.

1. We'd need to implement, both in pure-PHP and the PHP C extension, the code to expose options protos from the *Descriptor classes. A good model for this would be the Ruby support for descriptor options, which was added somewhat recently in https://github.com/protocolbuffers/protobuf/pull/14594.
2. We would need to make a decision how to handle immutability for those options protos. In other languages, the returned options are usually immutable, but PHP doesn't currently have any facility for making messages immutable. We would either need to add support for immutability, or have the accessors for options protos return a new copy of the options (ie. not shared).
3. To expose custom options, as opposed to built-in options, we'll also need to support extensions in PHP. PHP currently doesn't support extensions, so this would be a new feature in general for message objects.

We don't have anyone working on this currently.

[francislavoie]

We would need to make a decision how to handle immutability for those options protos. In other languages, the returned options are usually immutable, but PHP doesn't currently have any facility for making messages immutable.

PHP has the readonly keyword, which is effective immutability. It makes properties "write-once", and throws an error on any attempt to change the value thereafter. See https://php.watch/versions/8.1/readonly

[haberman]

To use readonly I think we'd need to have separate types. For example, given a message Foo, we currently generated a PHP class Foo. Would we also need to generate a separate class ReadonlyFoo? That would be a major change to the generated API.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.