On Thu, Sep 28, 2017 at 11:15:52AM -0700, Jim Blandy wrote: > 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.
We could make it a little looser than that, so that... > > > > (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? we could keep some related members together for these larger classes. Something like "Please keep data fields together either all at the start or all at the end of the class. Where a class has many roles the members and functions may be grouped into those roles for easier reading." > 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. That's probably also a good idea, but something to work towards in the longer term perhaps or for new classes? Keeping things on role-like groups probably has a better chance of being followed in the short term ;-) Generally I definitly agree. Both these things (keeping data members together and generally grouping them) would make reading the SM sources easier for me. > 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. That's true also. There are probably a number of exceptions we can find to any proposed "rules". -- Paul Bone http://paul.bone.id.au _______________________________________________ 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
