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

PHP custom options not available #3065

Open
camuthig opened this issue May 5, 2017 · 12 comments
Open

PHP custom options not available #3065

camuthig opened this issue May 5, 2017 · 12 comments

Comments

@camuthig
Copy link

camuthig commented May 5, 2017

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
Copy link
Contributor

TeBoring commented May 5, 2017 via email

@camuthig
Copy link
Author

camuthig commented May 5, 2017

@TeBoring do you have any timeline for the functionality?

@TeBoring
Copy link
Contributor

TeBoring commented May 5, 2017 via email

@TeBoring TeBoring added the php label May 6, 2017
@francislavoie
Copy link

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
Copy link
Contributor

TeBoring commented Nov 8, 2017 via email

@phphphphphp
Copy link

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
Copy link
Member

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
Copy link
Contributor

esorot commented Sep 1, 2022

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

@calvin2021y
Copy link

@haberman @esorot

any update?

@haberman
Copy link
Member

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 Add support for options in CRuby, JRuby and FFI #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
Copy link

francislavoie commented Feb 15, 2024

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
Copy link
Member

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.

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

No branches or pull requests

8 participants