There's also `ddbug`[0] for dumping layouts, but while such tools are useful, its annoying to be staring at a struct definition and not know what data members exist because their definitions interspersed with methods...
[0] https://github.com/philipc/ddbug On Fri, Sep 29, 2017 at 2:43 AM, Lars Hansen <lhan...@mozilla.com> wrote: > On Thu, Sep 28, 2017 at 9:35 PM, Jason Orendorff <jorendo...@mozilla.com> > wrote: > > > On Thu, Sep 28, 2017 at 2:10 AM, Lars Hansen <lhan...@mozilla.com> > wrote: > > > >> I dislike this proposal. (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. (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. (c) It brings private and public parts of the code close > >> together, and separates public data from public methods. > >> > > > > Objections (a) and (b) make sense to me, so let's make the rule "For > > reasonable-sized classes, put all the fields together, at the top > > (immediately after any necessary typedefs). For unreasonably large > classes, > > do whatever seems best (but let's try to avoid making more of these)." > > Better? > > > > Much better. > > > > > > I don't really understand objection (c); maybe an example from SM code > > would clear it up. (But let me grant in advance that all style rules are > > subordinate to George Orwell's sixth rule: "Break any of these rules > sooner > > than say anything outright barbarous.") > > > > I admit this is a more generic concern. When I write code that is part of > a module API I like to separate the public bits from the private bits and I > usually do this textually (public members and methods at the top; private > at the bottom) since C++ pretty much forces me to add the private bits to > the publically visible class definition unless I want to jump through a lot > of hoops to hide them and pay the cost of virtual methods. > > --lars > , still misses Modula-3's partial revelations > > > > > > -j > > > > > _______________________________________________ > 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 > _______________________________________________ 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
