Collection properties as mutable types
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by tracing ListProperty and SettingsManager, especially how defaults and current values are returned and stored. Compare the proposed always-mutable current value with the alternative helper API and check related collection-property behavior. Done requires a maintainer-approved design and tests showing default values remain immutable while current collection values support mutation.
Written by the indexing model from the issue text.
Description
I think it makes sense to have default values of list properties, set properties and similar immutable, but it's a bit cumbersome to have to work around the current value being immutable whenever we want to add or remove a value. It might make sense to just always hold the default value as mutable (i.e. by copying the default value over into an ArrayList or similar when it's not in the resource), or by providing a method that redefines the list to be mutable if needed (for ListProperty):
public List<E> getOrInitAsMutableList(@NotNull SettingsManager settingsManager) {
List<E> value = settingsManager.getProperty(this);
if (value.getClass() != ArrayList.class) {
value = new ArrayList<>(value);
settingsManager.setProperty(this, value);
}
return value;
}
I think ideally we have the default value immutable, the current value always mutable. I don't think the performance impact of copying over entries should be noticeable.
- Dominant language
- Java
- Stars
- 44
- Forks
- 21
- Avg merge
- 7d 11h
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
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.
More from AuthMe/ConfigMe
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
-
architecture
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
PropertyValue: Specify if value is default or notMay be free again @ljacqu claimed this 79 days ago, and no pull request is open. Open
Similar issues
-
new feature
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/rocketmq-dashboard#5594 ·
Maintainers usually reply within 3 days
-
bug pkg:sdk
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
aws/aws-durable-execution-sdk-java#773 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PCL-Community/PCL-CE#3652 ·
Maintainers usually reply within 1 day
-
TaskSecret.vue: replace explicit `any` with real typesPossibly taken @prayas-bit claimed this today. Openarea/frontend good first issue kind/cooldown
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
kestra-io/kestra#20352 · 1 comment ·
Maintainers usually reply within 1 day