[jira] [Updated] (BEAM-3295) Consider: make KV more convenient

["Robert Burke (Jira)" <ji...@apache.org>]

     [ 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)