From:  Jim Blandy <jblandy@mozilla.com>
Date:  29 Sep 2017 02:15:52 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: C++ coding style rule for keeping class fields together

NNTP-Posting-Host:  63.245.214.181

On Thu, Sep 28, 2017 at 12:10 AM, Lars Hansen  wrote:

> (a) A lot of the code I work with already have
> fields-at-the-beginning as the predominant pattern in the smaller classes
> (jit, wasm) so this would be major churn for no gain.


I think changing the proposal to allow "all at start or all at end" would
be a friendly amendment.

>
> (b) For large classes this is an anti-pattern, like having all the vars at
> the beginning
> of a function in C; it separates the data from the functions that work on
> that data.


So, one corollary of this is that reading a group of data members together
with their functions, *and not the rest of the class*, usually tells you
what you needed to know, correct?

If that's actually true, then I'd argue that the class should be broken up
into smaller types, since apparently one set of fields can be manipulated
without regard to the others. Permitting mixed data and methods is enabling
poor style.

On the other hand, if, in fact, it is not safe to manipulate those fields
independently, then separating those fields from the others they
participate in invariants with is misleading.

The benefit of seeing all the members together is that it's much easier to
see which invariants the members have with respect to each other, which for
me is pretty much "how this class works". The methods just advance the
members from one good state to another as desired.


> (c)  It brings private and public parts of the code close
> together, and separates public data from public methods.
>

This, I'm more sympathetic to. Setting out the public API clearly is a win.
I haven't seen too many Rust types that mix public and private members,
though.