- 23 Feb, 2020 2 commits
-
-
Eric Myhre authored
This first crossed my mind when considering whether it might be a good idea to export the concrete implementation types of the 'basicnode' package (see previous couple of commits -- it mostly had to do with the question of whether we could reuse more code and shrink the size of packages emitted by codegen)... but even though that's resolved to a pretty solid "nope", it still makes sense to have a consistent name prefix pattern here... and we'll probably encourage and expect to see similar conventions in other packages (including in codegen, if we add a handy-constructor-funcs feature to that).
-
Eric Myhre authored
-
- 20 Feb, 2020 1 commit
-
-
Eric Myhre authored
Turns out there was a lot of tech debt already accumulating very very rapidly due to the earlier whimiscal choice to lump the new basicnode implementations and the demo-codegen implementations into the same packages as benchmarking and research on this branch began. The basicnode package is now extracted cleanly, and exists in the 'node/basic' path. This 'basicnode' package is the equivalent of what was formerly called 'ipldfree' on the master branch. The demo codegen content is now under 'node/gendemo'. Note that it is BROKEN in this commit; there was too much there to clean up and address in one commit, and this one has already become quite large and includes a bewildering number of moves as well as finer content rearrangements. Fixes will come in next commit(s). (Why? Well, the demo codegen content leaned on the basicnode types for string and int. Turns out this actually opens *quite* the can of worms when you try to rectify it. At the surface level, the basicnode package's types aren't exported. Could we export them? Well, sure. Except that's only half the trick. Can we export the *assemblers* for those types? Well, sure. But... Can we export the 'w' fields for those assemblers for those types? **NO** -- this is where it all breaks down -- if those fields are exported, we lose all control over all immutability everywhere. Shoot...? Very shoot. One clearly correct solution to this is to generate new types for all of the primitive scalars in every codegen output package; the downside, obviously, is that's a bit verbose in resulting code. There might be another very alexandrian solution to this gordian knot: exporting the basicnode package's types after all, but not their assemblers; then leaning further into their implementation detail of being implemented as typedefs rather than strictly enclosed structs, and having every part of codegen types that handle primitive leafs directly perform and manage the relevant casts. The bigger picture wisdom of this has not been completely analyzed yet.) The 'impls' path has in general become 'node'. This will stay this way when we finally merge over core on master; all the current 'impl' (without the s; sigh) paths will become 'node'. Numerous new HACKME files have appeared; some are splits of old ones to account for the new package splits; some are hoisted and polished from what were previously commentstorms in the code; some are completely new. There are also a few new package-scope godocs. The benchmarks and tests are rearranged and much (much) improved. Naming is more consistent; and things are consistently extracted to the 'node/mixins/tests' package, and imported and used from there. (If you want all the same benchmark info as before, you'll now have to run benchmarks from several different packages.)
-