[
https://issues.apache.org/jira/browse/FLINK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15469960#comment-15469960
]
ASF GitHub Bot commented on FLINK-3042:
---------------------------------------
Github user twalthr commented on a diff in the pull request:
https://github.com/apache/flink/pull/2337#discussion_r77777227
--- Diff:
flink-core/src/main/java/org/apache/flink/api/common/typeinfo/TypeInformation.java
---
@@ -122,14 +123,25 @@
public abstract Class<T> getTypeClass();
/**
- * Returns the generic parameters of this type.
+ * Optional method for giving Flink's type extraction system
information about the mapping
+ * of a generic type parameter to the type information of a subtype.
This information is necessary
+ * in cases where type information should be deduced from an input type.
*
- * @return The list of generic parameters. This list can be empty.
+ * For instance, a method for a {@link Tuple2} would look like this:
+ * <code>
+ * Map m = new HashMap();
+ * m.put("T0", this.getTypeAt(0));
+ * m.put("T1", this.getTypeAt(1));
+ * return m;
+ * </code>
+ *
+ * @return map of inferred subtypes; it must not contain all generic
parameters as key;
--- End diff --
You are right, "it doesn't have to contain..." would be better. What I
wanted to say is: It is also ok to just supply partial type information for
generic parameters (so returning an empty map is always acceptable).
> Define a way to let types create their own TypeInformation
> ----------------------------------------------------------
>
> Key: FLINK-3042
> URL: https://issues.apache.org/jira/browse/FLINK-3042
> Project: Flink
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.10.0
> Reporter: Stephan Ewen
> Assignee: Timo Walther
> Fix For: 1.0.0
>
>
> Currently, introducing new Types that should have specific TypeInformation
> requires
> - Either integration with the TypeExtractor
> - Or manually constructing the TypeInformation (potentially at every place)
> and using type hints everywhere.
> I propose to add a way to allow classes to create their own TypeInformation
> (like a static method "createTypeInfo()").
> To support generic nested types (like Optional / Either), the type extractor
> would provide a Map of what generic variables map to what types (deduced from
> the input). The class can use that to create the correct nested
> TypeInformation (possibly by calling the TypeExtractor again, passing the Map
> of generic bindings).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
