Bundle implementation details into nested member that is better isolated

When hiding implementation details in accessible places (and especially a dynamic language) it definitely pays to use symbols that have low accidental collision likelihood.

Take our static member called _id for example (https://github.com/jdiaz5513/capnp-ts/blob/master/packages/capnp-ts/src/std/schema.capnp.ts#L149). I’m sure there’s some other library out there somewhere that decided they’d hide _id members on class (constructor) objects, for us to collide with.

I noticed the official C++ compiler does the following: https://github.com/capnproto/capnproto/blob/master/c%2B%2B/src/capnp/schema.capnp.h#L95

Its nested bundle has two nice features IMO. 1. It’s got a very project / tool specific name, so other systems are less likely to conflict. 2. Even if autocomplete / intellisense / whatever is aware of the implementation detail members it sucks them into a single ignorable entry in the list.

Therefore, I propose we take a similar approach with the implementation details that we’re bundling into types.

[kentonv]

ES6 also has “symbols” – special field names that are not strings, and can be kept strictly private.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol

There appear to be polyfills available that fall back to obfuscated names under ES5.

Symbols can be clunky to work with, though.

[jdiaz5513]

Resolved with #98.