Github user chinmaykolhatkar commented on a diff in the pull request:
https://github.com/apache/incubator-apex-malhar/pull/142#discussion_r48224576
--- Diff:
library/src/main/java/com/datatorrent/lib/simple/SingleInputOutput.java ---
@@ -0,0 +1,64 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package com.datatorrent.lib.simple;
+
+import com.datatorrent.api.DefaultInputPort;
+import com.datatorrent.api.DefaultOutputPort;
+import com.datatorrent.api.annotation.Name;
+import com.datatorrent.api.annotation.Stateless;
+import com.datatorrent.common.util.BaseOperator;
+
+/**
+ * A base implementation of an operator that abstracts away the input and
output port.
+ *
+ * Subclasses should provide the implementation to process a tuple of type
I and return a tuple of
+ * type O.
+ *
+ * <p>
+ * <b>Input Port :</b><br>
+ * <b> input :</b> default input port. <br>
+ * <br>
+ * <b>Output Port :</b><br>
+ * <b> output :</b> default output port. <br>
+ * <br>
+ * <b>Stateful : No</b>, all state is handled through the implementing
class. <br>
+ * <b>Partitions : Yes</b>, no dependency among input tuples. <br>
+ * <br>
+ * @displayName Single Input & Output
+ * @category Simple Operators
+ * @tags simple, single input, single output
+ * @param <I> type being received from the input port
+ * @param <O> type being sent from the output port
+ * @since 3.3.0
+ */
+@Stateless
+@Name("single-input-output")
+public abstract class SingleInputOutput<I, O> extends BaseOperator
--- End diff --
A suggestion here:
From what I see is user will always have to return the call of process
method as soon as possible and that too with tuple that can be emitted. I think
there are couple of cases here which either needs to be documented or handled
in this code.
1) What if process method returns null?
2) What if process method throws exception?
3) Should user be allowed to block the process method call as this will
block the operator thread? If not, then this should be documented.
What is suggest is restructuring the code in following way:
1) Have exposed 2 methods:
a. process: where tuple is to be process. This is abstract method.
b. emitResult (or any better name): This is implemented method in this
abstract class, which user can call dependending on when the tuple needs to
be emitted.
This way, the process and emit part are decoupled and user of this class
gets a better control.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
