[
https://issues.apache.org/jira/browse/BEAM-6150?focusedWorklogId=175555&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-175555
]
ASF GitHub Bot logged work on BEAM-6150:
----------------------------------------
Author: ASF GitHub Bot
Created on: 14/Dec/18 19:14
Start Date: 14/Dec/18 19:14
Worklog Time Spent: 10m
Work Description: jklukas commented on a change in pull request #7160:
[BEAM-6150] Superinterface for SerializableFunction allowing declared exceptions
URL: https://github.com/apache/beam/pull/7160#discussion_r241860714
##########
File path: website/src/contribute/ptransform-style-guide.md
##########
@@ -395,8 +395,8 @@ If the transform has an aspect of behavior to be
customized by a user's code, ma
Do:
-* If possible, just use PTransform composition as an extensibility device -
i.e. if the same effect can be achieved by the user applying the transform in
their pipeline and composing it with another `PTransform`, then the transform
itself should not be extensible. E.g., a transform that writes JSON objects to
a third-party system should take a `PCollection<JsonObject>` (assuming it is
possible to provide a `Coder` for `JsonObject`), rather than taking a generic
`PCollection<T>` and a `SerializableFunction<T, JsonObject>` (anti-example that
should be fixed: `TextIO`).
-* If extensibility by user code is necessary inside the transform, pass the
user code as a `SerializableFunction` or define your own serializable
function-like type (ideally single-method, for interoperability with Java 8
lambdas). Because Java erases the types of lambdas, you should be sure to have
adequate type information even if a raw-type `SerializableFunction` is provided
by the user. See `MapElements` and `FlatMapElements` for examples of how to use
`SimpleFunction` and `SerializableFunction` in tandem to support Java 7 and
Java 8 well.
+* If possible, just use PTransform composition as an extensibility device -
i.e. if the same effect can be achieved by the user applying the transform in
their pipeline and composing it with another `PTransform`, then the transform
itself should not be extensible. E.g., a transform that writes JSON objects to
a third-party system should take a `PCollection<JsonObject>` (assuming it is
possible to provide a `Coder` for `JsonObject`), rather than taking a generic
`PCollection<T>` and a `ProcessFunction<T, JsonObject>` (anti-example that
should be fixed: `TextIO`).
+* If extensibility by user code is necessary inside the transform, pass the
user code as a `ProcessFunction` or define your own serializable function-like
type (ideally single-method, for interoperability with Java 8 lambdas). Because
Java erases the types of lambdas, you should be sure to have adequate type
information even if a raw-type `ProcessFunction` is provided by the user. See
`MapElements` and `FlatMapElements` for examples of how to use
`ProcessFunction` and `InferableFunction` in tandem to provide good support for
both lambdas and concrete subclasses with type information.
Review comment:
Changed wording of the last sentence here to remove reference to Java 7 and
instead discuss type inferability.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 175555)
Time Spent: 50m (was: 40m)
> Provide alternatives to SerializableFunction and SimpleFunction that may
> declare exceptions
> -------------------------------------------------------------------------------------------
>
> Key: BEAM-6150
> URL: https://issues.apache.org/jira/browse/BEAM-6150
> Project: Beam
> Issue Type: Improvement
> Components: sdk-java-core
> Reporter: Jeff Klukas
> Assignee: Jeff Klukas
> Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Contextful.Fn allows subclasses to declare checked exceptions, but neither
> SerializableFunction nor SimpleFunction do. We want to add a new entry in
> each of those hierarchies where checked exceptions are allowed. We can then
> change existing method signatures to accept the new superinterfaces in
> contexts where allowing user code to throw checked exceptions is acceptable,
> such as in ProcessElement methods.
> Discussed on the dev mailing list:
> https://lists.apache.org/thread.html/eecd8dea8b47710098ec67d73b87cf9b4e2926c444c3fee1a6b9a743@%3Cdev.beam.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
