flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <se...@apache.org>
Subject Re: Separation Between Scala and Java TypeExtractor
Date Tue, 06 Jan 2015 12:16:43 GMT
Okay. My last question was aiming towards whether we can consolidate code
there and not have two redundant paths (in scala and in java)

On Tue, Jan 6, 2015 at 12:18 PM, Aljoscha Krettek <aljoscha@apache.org>
wrote:

> Sorry, for the long wait, I had to retry some of my earlier tests.
>
>
>
> On Tue, Jan 6, 2015 at 11:04 AM, Stephan Ewen <sewen@apache.org> wrote:
> > Some questions to understand that better:
> >
> >  - When can the Scala type extractor not determine the same than the Java
> > one? What additional cases could the Java Type Extractor find?
>
> For a reason I could not discover yet, a Scala Macro cannot see
> private fields of
> a Java Class. Thus the Scala TypeExtraction logic would falsely assume that
> a type is a Pojo while it is in reality not. Those cases, the Java
> Extractor
> can handle.
>
> >  - How do you distinguish between a Java-created and a Scala-created
> class?
>
> Scala Reflection Type has a method "isJava":
> tpe.typeSymbol.asClass.isJava == true
> for Java-defined classes
>
> >  - Does it make sense to use the same logic for both, i.e. in Java we
> give
> > it the "Class" or "Parameterized Type", in Scala we give it the
> "ClassTag"
> > or list of class tags for all generics?
>
> What exactly are you suggesting?
>
> > Stephan
> >
> >
> > On Tue, Jan 6, 2015 at 11:00 AM, Aljoscha Krettek <aljoscha@apache.org>
> > wrote:
> >
> >> Hi,
> >> Right now, the Scala Type Extraction logic falls back to using the
> >> Java TypeExtractor when it encounters a class that was written in Java
> >> or when it cannot analyse a Scala Type. I did this because the Java
> >> TypeExtractor might catch some additional cases. The other option
> >> would be to directly fall back to the GenericTypeInfo when a type is
> >> defined in Java or when we cannot analyse a type.
> >>
> >> What do you think? How should we handle this?
> >>
> >> Cheers,
> >> Aljoscha
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message