This works fine, of course. And Claude, our slave of steel, doesn’t mind the extra typing and isn’t concerned that it will strike the wrong key.
This is an interesting example of how Claude’s style might differ from ours. I’d love to start a long-term thread collecting examples of how (and where possible, why) Claude’s code differs from our own, and whether we should teach Claude to code like we do or whether we might learn from its example.
Yes! An interesting challenge is doing the mapping to/from designators. We human’s ask for the parent as our inner abstraction of the app’s data (surfaced via the doc Outline) find it easier than remembering the name (if unique) or path of the desired object. For our slaves of steel, it is likely the opposite, where having to learn the abstraction just to get at the human’s internal model is wasteful effort.
We (humans) can, of course, surface the paths implicit in designators: for instance, in children. So, such a ‘reverse’ look-up is possible, though we have little personal value for that, as the data is longer and less memorable (for the human brain). Indeed, the result of children might be 10s or 100s of paths, yet all encapsulated by/abstracted to one short string.
Beyond being a useful shorthand the designators are also semantically different in ways that affects correctness as the document changes. When you list out all the children, that’s it — those are the notes you get. If you add or remove them, or change their names then your code breaks. Claude is creating fragile logic here.