You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing I didn't like about the recent changes to allow overriding lookup data (issue #472, PR #490) is that it requires the developer to create a ModelListing instance at runtime and manually find a VarSpec for the purposes of identifying the variable to be overridden.
Both ModelListing and VarSpec were previously implementation (or hidden API) details that were meant for advanced use cases (like in testing tools for accessing implementation variables), and I think it was a mistake to make developers have to understand these details.
It would be more convenient for developers if they can simply provide a variable name or ID to identify the variable.
Current:
// Read the JSON model listingconstlistingJson=awaitreadFile(joinPath('sde-prep','build','processed.json'),'utf8')constlisting=newModelListing(listingJson)// Find the `VarSpec` that corresponds to a certain variableconstlookupVarSpec=listing.varSpecs.get('_a_data[_a1]')// Create a `LookupDef` to override data for a variableconstlookupDef=createLookupDef(lookupVarSpec,[...])
Proposed:
// Create a `LookupDef` to override data for a variable (can now simply provide the variable name)constlookupDef=createLookupDef({varName: 'A data[A1]'},[...])// Or you can provide the variable IDconstlookupDef=createLookupDef({varId: '_a_data[_a1]'},[...])
For this to work, it will be necessary to bundle a minimal model listing with the generated model code. This feature (overriding lookup data) isn't likely to be needed for many models and bundling the listing would increase the size of the generated code, so I think I will make it an opt-in thing for now.
Once this change is implemented, ModelListing and VarSpec can go back to being implementation details and can be hidden from the public API for the time being.
The text was updated successfully, but these errors were encountered:
One thing I didn't like about the recent changes to allow overriding lookup data (issue #472, PR #490) is that it requires the developer to create a
ModelListing
instance at runtime and manually find aVarSpec
for the purposes of identifying the variable to be overridden.Both
ModelListing
andVarSpec
were previously implementation (or hidden API) details that were meant for advanced use cases (like in testing tools for accessing implementation variables), and I think it was a mistake to make developers have to understand these details.It would be more convenient for developers if they can simply provide a variable name or ID to identify the variable.
Current:
Proposed:
For this to work, it will be necessary to bundle a minimal model listing with the generated model code. This feature (overriding lookup data) isn't likely to be needed for many models and bundling the listing would increase the size of the generated code, so I think I will make it an opt-in thing for now.
Once this change is implemented,
ModelListing
andVarSpec
can go back to being implementation details and can be hidden from the public API for the time being.The text was updated successfully, but these errors were encountered: