Incorporation of variables for Data
types
#63
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a first take at introducing variables as outlined in #11. It is a slight modification compared to the original proposal from my end to allow for declaring variables as well on the
abstract type
level. In addition, the filtering is used to avoid that a user must create two new functions. Instead, the design is similar to creating new variables for an element.All data variables are created for a subtype of
AbstractElement
. This implies that functions must be created for each individual subtype. This is in line with the existing philosophy.I included the approach as well for
InvData
to illustrate the application.The PR also includes a renaming of
Data
toExtensionData
as proposed in #11. If undesired, we can revert the commit. Note that it is hence better to look directly at the individual commits.Deprecated versions left within the code base
The following functionality is retained, but will be removed in a breaking release:
Data
.variables_capex
increate_model
as well as the functions forLink
andNode
.