[
https://issues.apache.org/jira/browse/BEAM-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burke updated BEAM-3295:
-------------------------------
Resolution: Abandoned
Status: Resolved (was: Open)
Marking Abandoned, but the core ideas live on in how we can apply this via a
generic Go KV type. However, we don't need this issue to track that work at
this time.
> 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: P3
>
> 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
(v8.20.1#820001)
