Henning Rohde created BEAM-3295:
-----------------------------------
Summary: Consider: make KV more convenient
Key: BEAM-3295
URL: https://issues.apache.org/jira/browse/BEAM-3295
Project: Beam
Issue Type: Improvement
Components: sdk-go
Reporter: Henning Rohde
Priority: Minor
The KV design makes it implicit (and hence a second-class value). We currently
need to shim a KV into a struct for certain operations that work without such
need in Java (where KV is a first-class value). This is a tax to users. Maybe
we should, say:
(1) make utilities for pair predicates, etc and have top.Largest,
filter.Include accept KV input and a multi-arity functions?
(2) automatically generate KV types implicitly plus helpers to generate
component-wise operations on such types? top.Largest would then do have to be
changed.
(3) add nested KV in some cases and either not allow runtime user
manipulation (via beam.T, say) or via a nestable func () (A,B). Less obvious is
a good the emitter form.
(4) something else? (or do nothing)
Approach 1 is essentially to embrace the 2nd class nature of KVs and make it
more convenient to manage the different cases (such as in debug.Printf) whereas
approach 2 is to coerce KVs into 1st class values easily/on demand and add
utilities to help work with these values. Option 3 would make KV more -- but
not fully -- 1st class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
