You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Henning Rohde (JIRA)" <ji...@apache.org> on 2017/12/05 21:52:00 UTC

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

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)