Repository navigation
[FR] Improvement: Change updateChildren parameter to Map<String, ?> #917
Description
Activity
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
I'm new to contributing,sorry if it is not practical enough please let me know if this approach needs refinement!
Solution:
Add wrapper methods that accept Map<String, ?> and internally convert to Map<String, Object> before delegating to the existing methods. This preserves the current public API while enabling support for Map.of(...), Kotlin inline maps, and Groovy builders.
something similar to this:
// Helper: convert any Map<String,?> to Map<String,Object>
private static Map<String, Object> toObjectMap(Map<String, ?> src) {
Map<String, Object> dst = new HashMap<>(src.size());
src.forEach((k, v) -> dst.put(k, v));
return dst;
}
// Wrapper (sync) - forwards to existing API
public void updateChildrenFromAny(Map<String, ?> updates) {
updateChildren(toObjectMap(updates));
}// Wrapper (async) - forwards to existing async API
public Task updateChildrenFromAnyAsync(Map<String, ?> updates) {
return updateChildrenAsync(toObjectMap(updates));
}
Is your feature request related to a problem? Please describe.
Various builders (e.g.,
Map.of) and language features (e.g., Groovy and Kotlin inline maps) createMapinstances whoseVbound is more strict thanObject. Currently, theDatabaseRef#updateChildren[Async]interface won't accept these instances because it is defined as acceptingMap<String, Object>.Describe the solution you'd like
Since these method consume the map and do not modify it, they could be defined as
Map<String, ?>to accept a map with any generic value type with no backwards incompatibility or other code changes.Describe alternatives you've considered
Otherwise, passing in maps usually requires an explicit type declaration instead of
varor an inline builder.