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 <aljos...@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 <se...@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 <aljos...@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 > >> >
