[
https://issues.apache.org/jira/browse/GEODE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967908#comment-15967908
]
ASF subversion and git services commented on GEODE-1577:
--------------------------------------------------------
Commit 4816d39402bf1b2d0ed7ea347695b2aef46a45cb in geode's branch
refs/heads/feature/GEODE-2632 from [~dalyssakim]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=4816d39 ]
GEODE-1577: Unhelpful generic types on Execution.execute
* Replaced wildcards with <T, S> for non-deprecated Execution.execute methods.
* descriptions added for params <T, S> in javadoc
* explicit type casting removed
* This closes #321
> Unhelpful generic types on Execution.execute
> --------------------------------------------
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
> Issue Type: Bug
> Components: functions
> Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a
> ResultCollector with wildcards for the type.
> {code}
> public ResultCollector<?, ?> execute(
> Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for
> example counting the elements in a list. By returning a ResultCollector with
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
> public <T,S> ResultCollector<T, S> execute(
> Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the
> compiler could ensure that the types used by withCollector and the types used
> by execute match.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
