explore allowing components and datum to have the same name

[corakingdon]

What we talked about on Friday, i.e. that maybe FUND should be able to have a component named :population with a variable also called :population in the new shared namespace design. We said that to get this to work, we would check for namespace collisions at build time, instead of when the components get added in the definition, to allow name collisions to be resolved by internal connections.

@rjplevin I believe you are working on this?

[rjplevin]

I think the issue with :population name collision in FUND is because parameters and variables share a namespace Dict with components. Did I misunderstand this aspect of the design? It seems reasonable to propagate variables to enclosing components.

Perhaps the defaults should to be export parameters and not export variables? Or is exporting variables just not needed?

And if any params are exported explicitly, all non-explicitly-exported ones are not exported, right?

Alternatively, for simplicity, we might exporting only when explicit for both vars & params. Given that we have no composite models yet, it's not obvious what would be most convenient.

[corakingdon]

You're right, I characterized the problem in FUND wrong. I think the problem was that the "top" component had a component named :population, and then also a parameter named :population that had bubbled up from the :socioeconomics (and other components) that expected to be able to connect with the variable :population from the :population component.

I think the default should be to export all parameters that are not resolved by internal connections, but to not export variable names. I'm pretty sure our agreed upon design was that you have to explicitly export variables from leaf components if you want them to exist in the composite's namespace. Like: temperature = climate.temperature in the @defcomposite definition. We don't have a working composite model yet, but I think part of the reason we wanted to export all parameters was so that we have a consistent story at the "top" level of the model about what the external parameter names are, so that they all get set with consistent values, especially when multiple components rely on the same external parameter value.

Does it make sense, then, that the solution to this problem for FUND is that the check for name collisions shouldn't happen during the definition, but rather during build time? so that the following definition would work:

@defcomposite top begin
    component(population)
    component(socioeconomics)

    socioeconomics.population = population.population
end

Since the external parameter :population in the :socioeconomics component is connected to the variable from the population component, the only thing named :population that exists in this composite's namespace is the component :population.

[rjplevin]

Yes -- Thanks for writing it down!