On Thu, Sep 28, 2017 at 12:10 AM, Lars Hansen <lhan...@mozilla.com> 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. _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
