FieldOptions

Constructor.

No description

No description

No description

No description

No description

No description

Clear all containing fields.

Clear all unknown fields previously parsed.

Merges the contents of the specified message into current message.

This method merges the contents of the specified message into the current message. Singular fields that are set in the specified message overwrite the corresponding fields in the current message. Repeated fields are appended. Map fields key-value pairs are overwritten. Singular/Oneof sub-messages are recursively merged. All overwritten sub-messages are deep-copied.

Parses a protocol buffer contained in a string.

This function takes a string in the (non-human-readable) binary wire format, matching the encoding output by serializeToString(). See mergeFrom() for merging behavior, if the field is already set in the specified message.

Parses a json string to protobuf message.

This function takes a string in the json wire format, matching the encoding output by serializeToJsonString(). See mergeFrom() for merging behavior, if the field is already set in the specified message.

No description

Populates the message from a user-supplied PHP array. Array keys correspond to Message properties and nested message properties.

Example:

$message->mergeFromArray([
    'name' => 'This is a message name',
    'interval' => [
         'startTime' => time() - 60,
         'endTime' => time(),
    ]
]);

This method will trigger an error if it is passed data that cannot be converted to the correct type. For example, a StringValue field must receive data that is either a string or a StringValue object.

No description

No description

No description

No description

Serialize the message to string.

Serialize the message to json string.

No description

No description

The ctype option instructs the C++ code generator to use a different representation of the field than it normally would. See the specific options below. This option is not yet implemented in the open source release -- sorry, we'll try to include it in a future version!

Generated from protobuf field optional .google.protobuf.FieldOptions.CType ctype = 1 [default = STRING];

No description

No description

The ctype option instructs the C++ code generator to use a different representation of the field than it normally would. See the specific options below. This option is not yet implemented in the open source release -- sorry, we'll try to include it in a future version!

Generated from protobuf field optional .google.protobuf.FieldOptions.CType ctype = 1 [default = STRING];

The packed option can be enabled for repeated primitive fields to enable a more efficient representation on the wire. Rather than repeatedly writing the tag and type for each element, the entire array is encoded as a single length-delimited blob. In proto3, only explicit setting it to false will avoid using packed encoding.

Generated from protobuf field optional bool packed = 2;

No description

No description

The packed option can be enabled for repeated primitive fields to enable a more efficient representation on the wire. Rather than repeatedly writing the tag and type for each element, the entire array is encoded as a single length-delimited blob. In proto3, only explicit setting it to false will avoid using packed encoding.

Generated from protobuf field optional bool packed = 2;

The jstype option determines the JavaScript type used for values of the field. The option is permitted only for 64 bit integral and fixed types (int64, uint64, sint64, fixed64, sfixed64). A field with jstype JS_STRING is represented as JavaScript string, which avoids loss of precision that can happen when a large value is converted to a floating point JavaScript.

Specifying JS_NUMBER for the jstype causes the generated JavaScript code to use the JavaScript "number" type. The behavior of the default option JS_NORMAL is implementation dependent. This option is an enum to permit additional types to be added, e.g. goog.math.Integer.

Generated from protobuf field optional .google.protobuf.FieldOptions.JSType jstype = 6 [default = JS_NORMAL];

No description

No description

The jstype option determines the JavaScript type used for values of the field. The option is permitted only for 64 bit integral and fixed types (int64, uint64, sint64, fixed64, sfixed64). A field with jstype JS_STRING is represented as JavaScript string, which avoids loss of precision that can happen when a large value is converted to a floating point JavaScript.

Specifying JS_NUMBER for the jstype causes the generated JavaScript code to use the JavaScript "number" type. The behavior of the default option JS_NORMAL is implementation dependent. This option is an enum to permit additional types to be added, e.g. goog.math.Integer.

Generated from protobuf field optional .google.protobuf.FieldOptions.JSType jstype = 6 [default = JS_NORMAL];

Should this field be parsed lazily? Lazy applies only to message-type fields. It means that when the outer message is initially parsed, the inner message's contents will not be parsed but instead stored in encoded form. The inner message will actually be parsed when it is first accessed.

This is only a hint. Implementations are free to choose whether to use eager or lazy parsing regardless of the value of this option. However, setting this option true suggests that the protocol author believes that using lazy parsing on this field is worth the additional bookkeeping overhead typically needed to implement it. This option does not affect the public interface of any generated code; all method signatures remain the same. Furthermore, thread-safety of the interface is not affected by this option; const methods remain safe to call from multiple threads concurrently, while non-const methods continue to require exclusive access. Note that implementations may choose not to check required fields within a lazy sub-message. That is, calling IsInitialized() on the outer message may return true even if the inner message has missing required fields. This is necessary because otherwise the inner message would have to be parsed in order to perform the check, defeating the purpose of lazy parsing. An implementation which chooses not to check required fields must be consistent about it. That is, for any particular sub-message, the implementation must either always check its required fields, or never check its required fields, regardless of whether or not the message has been parsed. As of 2021, lazy does no correctness checks on the byte stream during parsing. This may lead to crashes if and when an invalid byte stream is finally parsed upon access. TODO(b/211906113): Enable validation on lazy fields.

Generated from protobuf field optional bool lazy = 5 [default = false];

No description

No description

Should this field be parsed lazily? Lazy applies only to message-type fields. It means that when the outer message is initially parsed, the inner message's contents will not be parsed but instead stored in encoded form. The inner message will actually be parsed when it is first accessed.

This is only a hint. Implementations are free to choose whether to use eager or lazy parsing regardless of the value of this option. However, setting this option true suggests that the protocol author believes that using lazy parsing on this field is worth the additional bookkeeping overhead typically needed to implement it. This option does not affect the public interface of any generated code; all method signatures remain the same. Furthermore, thread-safety of the interface is not affected by this option; const methods remain safe to call from multiple threads concurrently, while non-const methods continue to require exclusive access. Note that implementations may choose not to check required fields within a lazy sub-message. That is, calling IsInitialized() on the outer message may return true even if the inner message has missing required fields. This is necessary because otherwise the inner message would have to be parsed in order to perform the check, defeating the purpose of lazy parsing. An implementation which chooses not to check required fields must be consistent about it. That is, for any particular sub-message, the implementation must either always check its required fields, or never check its required fields, regardless of whether or not the message has been parsed. As of 2021, lazy does no correctness checks on the byte stream during parsing. This may lead to crashes if and when an invalid byte stream is finally parsed upon access. TODO(b/211906113): Enable validation on lazy fields.

Generated from protobuf field optional bool lazy = 5 [default = false];

unverified_lazy does no correctness checks on the byte stream. This should only be used where lazy with verification is prohibitive for performance reasons.

Generated from protobuf field optional bool unverified_lazy = 15 [default = false];

No description

No description

unverified_lazy does no correctness checks on the byte stream. This should only be used where lazy with verification is prohibitive for performance reasons.

Generated from protobuf field optional bool unverified_lazy = 15 [default = false];

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

Generated from protobuf field optional bool deprecated = 3 [default = false];

No description

No description

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

Generated from protobuf field optional bool deprecated = 3 [default = false];

For Google-internal migration only. Do not use.

Generated from protobuf field optional bool weak = 10 [default = false];

No description

No description

For Google-internal migration only. Do not use.

Generated from protobuf field optional bool weak = 10 [default = false];

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

Generated from protobuf field repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999;

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

Generated from protobuf field repeated .google.protobuf.UninterpretedOption uninterpreted_option = 999;