In the course of implementing #2139, the question of whether the daemon's provideWorker() should overwrite existing names corresponding to non-worker formulas. In general, if the daemon receives a command to create a value of type A with name foo, then we would like to either provide the existing foo if it is of type A, or assign a new value of type A to foo, thereby overwriting the old one. Currently, multiple problems stand in the way of realizing this:
The provideXyz() family of methods tend to return an existing value if its type corresponds to Xyz, and construct a new value otherwise. Following #2115, it is usually difficult to retrieve the type of existing values. Consequently, it is also difficult to determine whether a provideXyz() should overwrite an existing name or return the value of an existing name.
Certain methods let you specify the name of a particular type of value to be used for the creation of a new value. For example, evaluate() lets you specify the worker in which evaluation occurs. The retrieval process for this value currently suffers from an inability to determine in advance whether the specified worker name in fact corresponds to a worker value.
Moreover, there is a question of what to do when methods like evaluate() specify a name for a dependent value that corresponds to the wrong type. Should we:
Throw an error when this happens?
Call the corresponding provideXyz() method, thereby overwriting the old value?
In this case, we should be concerned about users accidentally overwriting values.
To resolve these problems, we need to consider what our story is for value provision and formula overwrites.
In the course of implementing #2139, the question of whether the daemon's
provideWorker()
should overwrite existing names corresponding to non-worker formulas. In general, if the daemon receives a command to create a value of typeA
with namefoo
, then we would like to either provide the existingfoo
if it is of typeA
, or assign a new value of typeA
tofoo
, thereby overwriting the old one. Currently, multiple problems stand in the way of realizing this:provideXyz()
family of methods tend to return an existing value if its type corresponds toXyz
, and construct a new value otherwise. Following #2115, it is usually difficult to retrieve the type of existing values. Consequently, it is also difficult to determine whether aprovideXyz()
should overwrite an existing name or return the value of an existing name.evaluate()
lets you specify the worker in which evaluation occurs. The retrieval process for this value currently suffers from an inability to determine in advance whether the specified worker name in fact corresponds to a worker value.evaluate()
specify a name for a dependent value that corresponds to the wrong type. Should we:provideXyz()
method, thereby overwriting the old value?To resolve these problems, we need to consider what our story is for value provision and formula overwrites.