[ 
https://issues.apache.org/jira/browse/FLINK-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095610#comment-16095610
 ] 

ASF GitHub Bot commented on FLINK-7194:
---------------------------------------

Github user sunjincheng121 commented on a diff in the pull request:

    https://github.com/apache/flink/pull/4379#discussion_r128660377
  
    --- Diff: 
flink-libraries/flink-table/src/main/scala/org/apache/flink/table/functions/aggfunctions/AvgAggFunction.scala
 ---
    @@ -80,11 +80,11 @@ abstract class IntegralAvgAggFunction[T] extends 
AggregateFunction[T, IntegralAv
         acc.f1 = 0L
       }
     
    -  def getAccumulatorType: TypeInformation[_] = {
    +  override def getAccumulatorType: TypeInformation[IntegralAvgAccumulator] 
= {
         new TupleTypeInfo(
           new IntegralAvgAccumulator().getClass,
    --- End diff --
    
    How about classOf[IntegralAvgAccumulator], Although classOf[T] is 
equivalent to the class literal T.class in Java. but I think it is more 
concise.What do you think?


> Add getResultType and getAccumulatorType to AggregateFunction
> -------------------------------------------------------------
>
>                 Key: FLINK-7194
>                 URL: https://issues.apache.org/jira/browse/FLINK-7194
>             Project: Flink
>          Issue Type: Improvement
>          Components: Table API & SQL
>    Affects Versions: 1.4.0
>            Reporter: Fabian Hueske
>            Assignee: Fabian Hueske
>
> FLINK-6725 and FLINK-6457 proposed to remove methods with default 
> implementations such as {{getResultType()}}, {{toString()}}, or 
> {{requiresOver()}} from the base classes of user-defined methods (UDF, UDTF, 
> UDAGG) and instead offer them as contract methods which are dynamically 
> In PR [#3993|https://github.com/apache/flink/pull/3993] I argued that these 
> methods have a fixed signature (in contrast to the {{eval()}}, 
> {{accumulate()}} and {{retract()}} methods) and should be kept in the 
> classes. For users that don't need these methods, this doesn't make a 
> difference because the methods are not abstract and have a default 
> implementation. For users that need to override the methods it makes a 
> difference, because they get IDE and compiler support when overriding them 
> and the cannot get the signature wrong.
> Consequently, I propose to add {{getResultType()}} and 
> {{getAccumulatorType()}} as methods with default implementation to 
> {{AggregateFunction}}. This will make the interface of {{AggregateFunction}} 
> more consistent with {{ScalarFunction}} and {{TableFunction}}.
> What do you think [~shaoxuan], [~RuidongLi] and [~jark]?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to