Devlog

These are my daily notes and internal conversations during development. They may be helpful to understand the larger context of decisions that were made, and how I learned and explored while building.

Devlog < 2023 < May < 9

| by date | | thread: co |

After asking around town, I found a really helpful answer to my question about "can 'example.name.test' point to an object if 'example.name' is also an object?" Essentially, according to set theory, a set cannot contain itself, so 'example.name' can't qualify further names. But, you can also think of a name as a set of path elements and an identifier at the end. That would mean that {example.}{name} is different than {example.}{name.} which solved the uncertainty in my mind.

However, this doesn't really help me choose which approach to take, it just lets me know both are valid. My gut feeling is that the "set theory" approach is cleaner and more in line with the philosophy of coalescent data, even though it's more restrictive. A hash-link points at an object, and that object self identifies; it could be a name table or anything else. If we wanted to do it in the path/identifier way, we'd need each link table to have separate sections for links to further name tables and links to data. This means we'd need to specify on the link side what type the linked data is, with no way of making sure that it obeys. In the other system, you'll never have that problem because you can just resolve the hash and any data that is found is legal.

So if we choose to say that a name can either be a data object *or* a path, we have a UX challenge to solve during a build. What happens if .co.example is a namespace with many children, but then a build tries to write a data object to .co.example? This could potentially delete hundreds or thousands of names by removing a high level link. At the very least, the CLI should give a warning that an import is about to delete X number of names. But it should also be designed to minimize the surface area of that conflict. How often do names need to actually be exported? There will be libraries whose purpose is to link names to commonly used code, and there will be applications and utility functions that are named because they are meant to be invoked, but can most things just not be exported to names? What would be the situation where you accidentally are overwriting names?

These questions have led me to consider whether "names" should, by default, only be internal to the build process. We want to be able to resolve the names in our source code files, but we don't necessarily want that to mean those names get exported.

| thread: co | | by date |