> On 一月 19, 2016, 10:18 p.m., Joseph Wu wrote:
> > src/common/resources.cpp, line 880
> > <https://reviews.apache.org/r/41772/diff/6/?file=1199181#file1199181line880>
> >
> >     It should be fine to just name this `flatten`.
> >     
> >     You should also consider changing the parameter type from 
> > `RevocableInfo::Type` to just `RevocableInfo`.  Supplying the whole 
> > `RevocableInfo` will save us another tweak to the helpers if we change the 
> > revocable protobufs again.
> 
> Guangya Liu wrote:
>     I think that we cannot rename it to `flatten` as the compiler will not 
> know what does `flatten()` mean.
> 
> Klaus Ma wrote:
>     Regarding from `RevocableInfo::Type` to `RevocableInfo`, do you mean 
> change `RevocableInfo` from `message` to `enum`? I think it's better to 
> define const in `Resources` instead of changing `RevocableInfo`'s type, e.g. 
> `static const Resource::RevocableInfo::Type Resources::ALLOCATION_SLACK = 
> Resource::RevocableInfo::Type::ALLOCATION_SLACK`.
>     
>     Regarding `flatten`, there're two options to me:
>     
>     * Option 1: add `RevocableInfo::Type` to as 3rd parameter in current 
> `flatten` with `None()` as default vaule, and a new helper function to accept 
> `RevocableInfo::Type` only without default value. The sample code is:
>     
>     ```
>         Resources flatten(string role = "*", Option<ReservationInfo> 
> resveration = None(), Option<RevocableInfo::Type> revocable = None()) {
>           ...
>           if (revocable.isSome()) {
>             flatten(revocable.get());
>           } else {
>             // clear revocable info.
>           }
>         }
>         
>         Resources flatten(RevocableInfo::Type revocable) {
>           foreach resources {
>             resource.mutable_revocable()->set_type(revocable);
>           }
>         }
>     ```
>     
>     * Option 2: add new `flatten` functions but did not provide default 
> value; `None()` means clear the `RevocableInfo::Type`.
>     
>     I perfer to Option 1 :). Any comments?
> 
> Guangya Liu wrote:
>     option 1 will cause all caller who want to flatten allocation slack need 
> to input all of the four parameter, it is really not convenient for the 
> caller.
>     Option 2 need to add a new `flatten` with a `requested` but not `option` 
> parameter, I think that maybe 2 is better.
> 
> Klaus Ma wrote:
>     regarding 1, if want to clear the flags (role, reservation and 
> revocable), call `flatten()`; if want to set `ALLOCATION_SLACK`, call 
> `flatten(Resources::ALLOCATION_SLACK)`.
> 
> Guangya Liu wrote:
>     Just clarify 1) here, I have some mis-understanding for it.
>     
>     Option 1) has involved two APIs, one is update current `Resources 
> flatten(string role = "*", Option<ReservationInfo> resveration = None(), , 
> Option<RevocableInfo::Type> revocable = None() )`, the other is add a new 
> `flatten(RevocableInfo::Type revocable)`. The `first flatten` is used to 
> clear `allocation slack` and the `second flatten` is used to set `allocation 
> slack` flag.
>     
>     Seems 1) is better as it faciliates the caller.
> 
> Joseph Wu wrote:
>     Given how you're using `flatten`, it would be better to have two calls:
>     `Resources flatten(string role = "*", Option<ReservationInfo> resveration 
> = None())`
>     and 
>     `Resources flatten(Option<RevocableInfo> revocable)`  // No default so 
> there's no ambiguity.
>     
>     ---
>     
>     Note: If you wanted a single `flatten`, you'd need to have 
> `Option<Option<ReservationInfo>>` so that you have the option of setting, 
> un-setting, or not-changing each field.

I think that adding a new `flatten` without default value might be better and 
clear.


- Guangya


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41772/#review115249
-----------------------------------------------------------


On 一月 20, 2016, 3:40 a.m., Guangya Liu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41772/
> -----------------------------------------------------------
> 
> (Updated 一月 20, 2016, 3:40 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Artem Harutyunyan, Joris Van 
> Remoortere, Joseph Wu, and Klaus Ma.
> 
> 
> Bugs: MESOS-4267
>     https://issues.apache.org/jira/browse/MESOS-4267
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Added helper function to flatten resources.
> 
> 
> Diffs
> -----
> 
>   include/mesos/resources.hpp cc8fef9470d779078aa408ed03e747e5a492deaa 
>   include/mesos/v1/resources.hpp f4892977f8d7b0439db6e9cf7921334f606a496c 
>   src/common/resources.cpp 575d6651185d8431f01d589f4afc255cb751181a 
>   src/tests/resources_tests.cpp b42610f1bf8eacfd7bf388d351f8745f1d96f666 
>   src/v1/resources.cpp 8de6672ba9b34947db81c74b8e03e8965e8af5fc 
> 
> Diff: https://reviews.apache.org/r/41772/diff/
> 
> 
> Testing
> -------
> 
> make
> make check
> 
> GLOG_v=2 ./bin/mesos-tests.sh  --gtest_filter="ResourcesOperationTest.*" 
> --verbose
> 
> 
> Thanks,
> 
> Guangya Liu
> 
>

Reply via email to