Skip to content

Enrich access to evaluator's variables#22

Merged
ctrueden merged 5 commits into
scijava:mainfrom
JaredDavis22:main
Jun 1, 2026
Merged

Enrich access to evaluator's variables#22
ctrueden merged 5 commits into
scijava:mainfrom
JaredDavis22:main

Conversation

@JaredDavis22
Copy link
Copy Markdown
Contributor

Small change to allow discovery of variable names.

@ctrueden
Copy link
Copy Markdown
Member

ctrueden commented Jun 1, 2026

@JaredDavis22 How would you feel about a new method:

public Map<String, Object> getVars() {
	return Collections.unmodifiableMap(vars);
}

You could then of course call .keySet() on the method's returned object to get the variable names. Or just iterate the entries directly. I'd like to avoid callers overwriting variables by direct map manipulation, because an alternative Evaluator implementation might rely on callers going through the set methods, for example. But at the same time, it's convenient to access an object representing the entire map, rather than only the key set.

@ctrueden
Copy link
Copy Markdown
Member

ctrueden commented Jun 1, 2026

As usual, I'm just waffling on naming. Do you like getAll() (for symmetry with setAll) or getVars more?

@JaredDavis22
Copy link
Copy Markdown
Contributor Author

getVars() approach works for me as well. Did the getNames approach allow for direct manipulation of the map? Was the direct manipulation comment justification for the Collections.modifiableMap wrapper?

getAll() seems better.

Is there a way to clear the map? setAll adds to existing map.

getAll() and clear() ?

@ctrueden
Copy link
Copy Markdown
Member

ctrueden commented Jun 1, 2026

Yeah, the direct manipulation comment was about returning a read-only map wrapper. I agree that getNames would not have allowed direct manipulation either—but you'd need to iterate over the keys and call get on each one to get all the values; a getAll with the map view itself seems more flexible here.

A clear() function totally makes sense. Do you think we need remove(String) as well? We probably shouldn't go overboard on implementing the entire Map interface contract... 😆

@JaredDavis22
Copy link
Copy Markdown
Contributor Author

adding remove does make sense. Let me add that.

What about testing/test cases?

@ctrueden
Copy link
Copy Markdown
Member

ctrueden commented Jun 1, 2026

I just whipped up some tests for get/set/getAll/setAll. Let me know when you're done on your side, and I can add them in.

@JaredDavis22
Copy link
Copy Markdown
Contributor Author

All set now

JaredDavis22 and others added 5 commits June 1, 2026 14:25
Co-authored-by: Curtis Rueden <ctrueden@wisc.edu>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Curtis Rueden <ctrueden@wisc.edu>
Signed-off-by: Curtis Rueden <ctrueden@wisc.edu>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
@ctrueden ctrueden changed the title Add getNames() to allow variable name discovery after an evaluation. Enrich access to evaluator's variables Jun 1, 2026
@ctrueden ctrueden merged commit 5e5ec87 into scijava:main Jun 1, 2026
1 check passed
@ctrueden
Copy link
Copy Markdown
Member

ctrueden commented Jun 1, 2026

@JaredDavis22 Thank you for contributing! I've released parsington 3.2.0 to Maven Central with these improvements. 🍻

@JaredDavis22
Copy link
Copy Markdown
Contributor Author

Wow - that was fast. Thanks for the great project!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants