proto library Client - Class MessageOptions (v5.36.2)

Reference documentation and code samples for the proto library Client class MessageOptions.

Generated from protobuf message google.protobuf.MessageOptions

Namespace

Google \ Protobuf \ Internal

Methods

__construct

Constructor.

Parameters
Name Description
data array

Optional. Data for populating the Message object.

↳ message_set_wire_format bool

Set true to use the old proto1 MessageSet wire format for extensions. This is provided for backwards-compatibility with the MessageSet wire format. You should not use this for any other reason: It's less efficient, has fewer features, and is more complicated. The message must be defined exactly as follows: message Foo { option message_set_wire_format = true; extensions 4 to max; } Note that the message cannot have any defined fields; MessageSets only have extensions. All extensions of your type must be singular messages; e.g. they cannot be int32s, enums, or repeated messages. Because this is an option, the above two restrictions are not enforced by the protocol compiler.

↳ no_standard_descriptor_accessor bool

Disables the generation of the standard "descriptor()" accessor, which can conflict with a field of the same name. This is meant to make migration from proto1 easier; new code should avoid fields named "descriptor".

↳ deprecated bool

Is this message deprecated? Depending on the target platform, this can emit Deprecated annotations for the message, or it will be completely ignored; in the very least, this is a formalization for deprecating messages.

↳ map_entry bool

Whether the message is an automatically generated map entry type for the maps field. For maps fields: map<KeyType, ValueType> map_field = 1; The parsed descriptor looks like: message MapFieldEntry { option map_entry = true; optional KeyType key = 1; optional ValueType value = 2; } repeated MapFieldEntry map_field = 1; Implementations may choose not to generate the map_entry=true message, but use a native map in the target language to hold the keys and values. The reflection APIs in such implementations still need to work as if the field is a repeated message field. NOTE: Do not set the option in .proto files. Always use the maps syntax instead. The option should only be implicitly set by the proto compiler parser.

↳ deprecated_legacy_json_field_conflicts bool

Enable the legacy handling of JSON field name conflicts. This lowercases and strips underscored from the fields before comparison in proto3 only. The new behavior takes json_name into account and applies to proto2 as well. This should only be used as a temporary measure against broken builds due to the change in behavior for JSON field name conflicts. TODO This is legacy behavior we plan to remove once downstream teams have had time to migrate.

↳ features FeatureSet

Any features defined in the specific edition. WARNING: This field should only be used by protobuf plugins or special cases like the proto compiler. Other uses are discouraged and developers should rely on the protoreflect APIs for their client language.

↳ uninterpreted_option array<UninterpretedOption>

The parser stores options it doesn't recognize here. See above.

getMessageSetWireFormat

Set true to use the old proto1 MessageSet wire format for extensions.

This is provided for backwards-compatibility with the MessageSet wire format. You should not use this for any other reason: It's less efficient, has fewer features, and is more complicated. The message must be defined exactly as follows: message Foo { option message_set_wire_format = true; extensions 4 to max; } Note that the message cannot have any defined fields; MessageSets only have extensions. All extensions of your type must be singular messages; e.g. they cannot be int32s, enums, or repeated messages. Because this is an option, the above two restrictions are not enforced by the protocol compiler.

Returns
Type Description
bool

hasMessageSetWireFormat

clearMessageSetWireFormat

setMessageSetWireFormat

Set true to use the old proto1 MessageSet wire format for extensions.

This is provided for backwards-compatibility with the MessageSet wire format. You should not use this for any other reason: It's less efficient, has fewer features, and is more complicated. The message must be defined exactly as follows: message Foo { option message_set_wire_format = true; extensions 4 to max; } Note that the message cannot have any defined fields; MessageSets only have extensions. All extensions of your type must be singular messages; e.g. they cannot be int32s, enums, or repeated messages. Because this is an option, the above two restrictions are not enforced by the protocol compiler.

Parameter
Name Description
var bool
Returns
Type Description
$this

getNoStandardDescriptorAccessor

Disables the generation of the standard "descriptor()" accessor, which can conflict with a field of the same name. This is meant to make migration from proto1 easier; new code should avoid fields named "descriptor".

Returns
Type Description
bool

hasNoStandardDescriptorAccessor

clearNoStandardDescriptorAccessor

setNoStandardDescriptorAccessor

Disables the generation of the standard "descriptor()" accessor, which can conflict with a field of the same name. This is meant to make migration from proto1 easier; new code should avoid fields named "descriptor".

Parameter
Name Description
var bool
Returns
Type Description
$this

getDeprecated

Is this message deprecated? Depending on the target platform, this can emit Deprecated annotations for the message, or it will be completely ignored; in the very least, this is a formalization for deprecating messages.

Returns
Type Description
bool

hasDeprecated

clearDeprecated

setDeprecated

Is this message deprecated? Depending on the target platform, this can emit Deprecated annotations for the message, or it will be completely ignored; in the very least, this is a formalization for deprecating messages.

Parameter
Name Description
var bool
Returns
Type Description
$this

getMapEntry

Whether the message is an automatically generated map entry type for the maps field.

For maps fields: map<KeyType, ValueType> map_field = 1; The parsed descriptor looks like: message MapFieldEntry { option map_entry = true; optional KeyType key = 1; optional ValueType value = 2; } repeated MapFieldEntry map_field = 1; Implementations may choose not to generate the map_entry=true message, but use a native map in the target language to hold the keys and values. The reflection APIs in such implementations still need to work as if the field is a repeated message field. NOTE: Do not set the option in .proto files. Always use the maps syntax instead. The option should only be implicitly set by the proto compiler parser.

Returns
Type Description
bool

hasMapEntry

clearMapEntry

setMapEntry

Whether the message is an automatically generated map entry type for the maps field.

For maps fields: map<KeyType, ValueType> map_field = 1; The parsed descriptor looks like: message MapFieldEntry { option map_entry = true; optional KeyType key = 1; optional ValueType value = 2; } repeated MapFieldEntry map_field = 1; Implementations may choose not to generate the map_entry=true message, but use a native map in the target language to hold the keys and values. The reflection APIs in such implementations still need to work as if the field is a repeated message field. NOTE: Do not set the option in .proto files. Always use the maps syntax instead. The option should only be implicitly set by the proto compiler parser.

Parameter
Name Description
var bool
Returns
Type Description
$this

getDeprecatedLegacyJsonFieldConflicts

Enable the legacy handling of JSON field name conflicts. This lowercases and strips underscored from the fields before comparison in proto3 only.

The new behavior takes json_name into account and applies to proto2 as well. This should only be used as a temporary measure against broken builds due to the change in behavior for JSON field name conflicts. TODO This is legacy behavior we plan to remove once downstream teams have had time to migrate.

Returns
Type Description
bool

hasDeprecatedLegacyJsonFieldConflicts

clearDeprecatedLegacyJsonFieldConflicts

setDeprecatedLegacyJsonFieldConflicts

Enable the legacy handling of JSON field name conflicts. This lowercases and strips underscored from the fields before comparison in proto3 only.

The new behavior takes json_name into account and applies to proto2 as well. This should only be used as a temporary measure against broken builds due to the change in behavior for JSON field name conflicts. TODO This is legacy behavior we plan to remove once downstream teams have had time to migrate.

Parameter
Name Description
var bool
Returns
Type Description
$this

getFeatures

Any features defined in the specific edition.

WARNING: This field should only be used by protobuf plugins or special cases like the proto compiler. Other uses are discouraged and developers should rely on the protoreflect APIs for their client language.

Returns
Type Description
FeatureSet|null

hasFeatures

clearFeatures

setFeatures

Any features defined in the specific edition.

WARNING: This field should only be used by protobuf plugins or special cases like the proto compiler. Other uses are discouraged and developers should rely on the protoreflect APIs for their client language.

Parameter
Name Description
var FeatureSet
Returns
Type Description
$this

getUninterpretedOption

The parser stores options it doesn't recognize here. See above.

Returns
Type Description
Google\Protobuf\RepeatedField<UninterpretedOption>

setUninterpretedOption

The parser stores options it doesn't recognize here. See above.

Parameter
Name Description
var array<UninterpretedOption>
Returns
Type Description
$this