<Property> , <Parameter>
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 11
- Forks
- 11
- Avg merge
- 8h 6m
- Merged PRs (30d)
- 1
Description
I am slightly confused by the usage of <Parameter> and <Property> given our discussions on "mutable parameters" (#32). Currently, it seems that <Parameter>s are only supposed to be set at <Component> creation time, whilst <Property>ies can be overridden with <Assign> under <Structure>. @robertcannon , how does that fit within our inheritance/overriding discussion? Didn't we say something about changing how <Structure> is handled?
In other words, how should an user specify that each one of the components in a population has a different value for one of its Parameters/Properties (or that all of them have the same value for the Parameter/Property except for one)?
There's <Constant> as well, which seems to allow <DerivedParameter>-like constructs. Would <DerivedParameter immutable="true"> make sense? (I am not convinced, just like in the <Child(ren)> case, just curious).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the inheritance/overriding discussion in TODO and issue #32, then trace how , , , , and are represented in the Java interpreter. This issue is done only after the project agrees on population-specific and overridden-value semantics and records or implements that decision.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100