Best Practice for Parameters used multiple places in the ResourceTree

[timsnyder]

Let's say you have something the config dumper would show as:

top:
    parent:
        params:
              meaning_of_the_universe: 42
        childA:
              params:
                    fooA: whatever
        childB:
              params:
                    fooB: morejunk

Now, let's say that parent, chlidA and childB all have behavior that depends on top.parent.params.meaning_of_the_universe, what's the best way for childA and childB to access the param?

There are also more convoluted cases where you have cousins spread out in the tree that need to know about each others' parameters. I know that depending on how you do this, you can run into tree build order issues if you walk the tree trying to look up parameter values.

Would it be useful for different Resources to be able to register as Observers of a View of other Resources' parameters? Or, is this intentionally not provided because it runs afoul of the Sparta design?

[furuame]

One scheme that I currently use (not invented by me though 😛): When a parent is constructing, it will also set children's (childA & childB's) parameters for configuring their behaviors.

Would it be useful for different Resources to be able to register as Observers of a View of other Resources' parameters?

I think that would be useful -- basically you're setting a 'formula' for a parameter based on another resource's parameter, right? Then we can save tons of setup codes in either parent or child node ..

Another risk I can think of is: what if multiple observers are registered to a parameters? Do you allow that? Otherwise, an precedence is required otherwise the value would be undeterministic.

[klingaard]

Zen's answer is right on target. The way I think about it is that the parent dictates the children's behavior, and since they are presumably tried at the hip w.r.t. that behavior, the parent should communicate down what the children should do.

To make this easier. however, that will require that the parent own/create the children outright, meaning that the parent's factory create those children during runtime and pass that behavior down during resource tree node creation. An example of that is here in the Olympia core model's execution pipeline.

In that example code, the Execute unit is the parent (top.cpu.core0.execute) and creates execution pipes (top.cpu.core0.execute.alu0_pipe for example) and determines which pipe is the branch pipe (by looking at its own parameters) and sets that pipe appropriately.

Sparta parameter ordering will allow those parameter in the child to be overridden.