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



docs/mesos-c++-style-guide.md
<https://reviews.apache.org/r/33558/#comment132034>

    Alternative suggestion:
    
    ```
    socket
      .send([]() {
        s1;
        s2;
      })
      .then([]() {
        s1;
        s2;
      })
      .then([]() {
        s1;
        s2;
      });
    ```
    
    Compare with existing method chain formatting without lambdas:
    
    ```
    async(&state::recover, metaDir, flags.strict)
      .then(defer(self(), &Slave::recover, lambda::_1))
      .then(defer(self(), &Slave::_recover))
      .onAny(defer(self(), &Slave::__recover, lambda::_1));
    ```
    
    It would also stay consistent when non-lambdas (e.g. defer), single-line 
lambdas and multi-line lambdas are all used:
    
    ```
    socket
      .send([]() { s1; })
      .then(defer(self(), &Self::reuseable_callback, lambda::_1))
      .then([]() {
        s1;
        s2;
      });
    ```
    
    What do you think? I know we had already talked about this, but I realized 
this later.


- Michael Park


On April 26, 2015, 1:23 a.m., Benjamin Hindman wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33558/
> -----------------------------------------------------------
> 
> (Updated April 26, 2015, 1:23 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Joris Van Remoortere, Michael Park, and 
> Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> See summary. Note that there will be a follow up review which enacts this 
> style in the code base.
> 
> 
> Diffs
> -----
> 
>   docs/mesos-c++-style-guide.md a9b56e3b5ef7e43af11903321d5c321c6203f79a 
> 
> Diff: https://reviews.apache.org/r/33558/diff/
> 
> 
> Testing
> -------
> 
> N/A
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Reply via email to