TSD Development:
The first thing to do is make a thing that accepts key-value pair assignments to make a tree.
Since kotlin readily supports map-like assignments, the first minor-leage case looks like this:
output["key"] = "value"That resembles a map, by design, but it isn’t one. Later cases will elaborate this, but the secret sauce is two-fold, consisting of a sequencing concept and a nesting concept.
Sequencing: the order in which keys are assigned values is preserved. Think in terms of a stream. If keys "a" & then "b" are assigned in that order, that’s a different thing than if keys "b" & then "a" are assigned.
Nesting: the values for these keys needn’t be strings or even single objects. An assignment like:
output["key"] = valuecan produce nesting, if value is one of the types that supports that. Some built-ins, like collections, do this automagically. Others do it via declaration.
Putting these three things together, the map-like syntax, the sequencing, and the nesting, is the desired outcome of the first round of tests and code.
Almost immediately, the question of interrogating these output objects jumps up. After all, how are we to know that output[key]=value works if we can’t interrogate ouput’s values somehow.
My gut is telling me I want client code that stuffs these trees to be entirely unaware of how to interrogate them. That’s easily done via separating interfaces, so there’s a TsdOutput interface and TsdTree that implements it. The tree can be interrogated if you know it’s a tree. What my gut isn’t telling me yet is the right syntax for that interrogation. I will start with something that is itself map-like, but the keys may not be the same as the input.
Further, almost as soon as I conceive this, I realize that "sequencing" isn’t really quite right. I suspect that what I really want is that the output trees are all normalized somehow, perhaps sorted by key. For the geek-young in the crowd, this process, of me wandering around my mental landscape, grabbing tools, guessing rules, leaving gaps, reversing myself, this is all pretty bog-standard design for me. It’s what I always do.
In this case, I’ve got a blank page. There aren’t really any rules until I make them up: I’m the customer. And let’s be clear, like every other customer on earth, I’m simultaneously picky, vague, and frequently wrong. "I’ll know it when I see it."
Also, I gold-plate, and I worry about shit that doesn’t matter, and I think too far ahead at times. 🙂
I’mo go take a swing at coding this up. Then we’ll see what we think when we hear what we say.