> On Feb 7, 2017, at 11:13 AM, Joris Van Remoortere <jo...@mesosphere.io> wrote:
>
>>
>> we should be able to not require them to be set and assume the defaults?
>
>
> What happens when we add a field without a default value to the message?
> If users can assume they don't need to set the message this may cause
> backwards compatibility issues in the future.
We can't. So this is why I said such message should semantically sound like a
config object with defaults. (I think the backoff example I gave fits this
criterion).
If we really need to add such a field, we would have to use a different message.
>
> Maybe I am not understanding whether you mean leaving the message unset, or
> the field?
I meant leaving the message unset.
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Thu, Feb 2, 2017 at 3:06 PM, Yan Xu <xuj...@apple.com> wrote:
>
>> With protobuf you can specify custom default values for scalar types
>> (proto2 at least) but not message types, e.g.,
>>
>> ```
>> message Filters {
>> // Time to consider unused resources refused. Note that all unused
>> // resources will be considered refused and use the default value
>> // (below) regardless of whether Filters was passed to
>> // SchedulerDriver::launchTasks. You MUST pass Filters with this
>> // field set to change this behavior (i.e., get another offer which
>> // includes unused resources sooner or later than the default).
>> optional double refuse_seconds = 1 [default = 5.0];
>> }
>> ```
>>
>> However, the message `Filters` essential has a default value because *all*
>> its
>> fields have default values. It all depends on whether the receiver chooses
>> to check it is not set or directly accesses it and gets the default values.
>>
>> When we reference the type in other messages, e.g.,
>>
>> ```
>> message Accept {
>> repeated OfferID offer_ids = 1;
>> repeated Offer.Operation operations = 2;
>> optional Filters filters = 3;
>> }
>> ```
>>
>> We are not explicitly telling users what's going to happen when `filters`
>> is not set. The master just directly uses it without checking.
>>
>> It does feel intuitive to me that "*if all the fields in a message have
>> default values, and it semantically feels like a config, then we can just
>> interpret them when unset as indication to use defaults*".
>>
>> However we probably should document it better.
>>
>> To generalize it further, for something like this with multiple fields
>>
>> ```
>> message ExponentialBackoff {
>> optional double initial_interval_seconds = 1 [default = 0.5];
>> optional double max_interval_seconds = 2 [default = 300.0];
>> optional double randomization_factor = 3 [default = 0.5];
>> optional double max_elapsed_seconds = 4 [default = 2592000.0];
>> }
>> ```
>>
>> we should be able to not require them to be set and assume the defaults?
>>
>> One step further, if the message has recursively nested messages with
>> default values, we can treat the parent message as having a default value
>> too?
>>
>> Thoughts?
>>
>> Yan
>>
